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PREFACE 


This  report  was  prepared  by  the  Institute  for  Defense  Analyses  (IDA)  for  the  Office 
of  the  Secretary  of  Defense,  Manpower,  Reserve  Affairs  and  Logistics  Under  Contract 
Number  MDA  903  84  C  0031,  Task  Order  T-3-192,  "R&D  Support  to  Improve  Force 
Readiness." 

The  issuance  of  the  report  answers  the  specific  task  to  "...assemble  a  group  of  both 
industry  and  government  personnel... experienced  in.. .computer-aided  technologies  for 
automation  of  support  procedures  in  order  to  examine  issues... include(ing)  the 
subcontractor  level,  inventory  management  techniques,  etc.  At  present  these  issues  are 
being  addressed  individually  without  apparent  consideration  of  their  interaction  in  meeting 
the  total  DoD  objective...to  evolve  a  general  plan  for  automated  support  of  DoD  operating 
systems  which  addresses  the  problems  of  interaction  between  the  different  systems  now  in 
use  or  evolving,  and  the  various  approaches  being  taken  by  DoD  to  address  its  readiness 
problems." 
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REPORT  OF  THE  TECHNICAL  ISSUES  SUBGROUP 


A.  SUMMARY 

\ 

The  Technical  Issues  Subgroup  has  considered  many  logistics  issues  and  selected 
four  of  particular  concern.  These  are:  immediate  needs  for  (1)  a  general  logistics 
information  model;  (2)  a  set  of  design  influence  algorithms  for  logistics;  (3)  a  logistics 
workstation;  and  (4)  a  kernel  logistics  system.  Each  of  these  items  is  recommended  for 
project  demonstration  -  probably  through  application  of  selected  expert/knowledge-based 
concepts  to  replace  the  data-based  techniques  now  in  general  use. 

The  Subgroup  considered  and  commented  on  several  additional  logistics  issues 
including  those  related  to  completely  integrated  system  operations,  proprietary  rights, 
embedded  electronics,  surge  situations,  standards  and  many  others.  Each  of  these  issues 
undoubtedly  is  important,  but  the  Subgroup  feels  that  most  of  them  should  be  ^revisited* 
(reassessed)  in  terms  of  scope,  objective,  impact  of  new  technology  and  sensitivity  to  non¬ 
technical  (policy  or  management)  influences. . 

The  Subgroup  members  provided  andcliscussed  22  reports  that  were  prepared  as 
Record  Documents  for  the  CALS  project  These  Documents  are  presented  in  Appendix  A 
to  this  report.  Several  informal  study  papers  and  particularly  relevant  document  excerpts 
from  other  sources  are  cited  in  the  List  of  Study  Papers  (Section  F),  but  are  not  included  in 
the  appendix. 

B.  APPROACH 

The  CALS  Technical  Issues  Subgroup  finds  that  its  overall  fields  of  interest  require 
critical  identification  because  many  issues  which  involve  their  Subgroup  appear  to  involve 
the  counterpart  interests  both  of  other  CALS  Subgroups  and  other  non-CALS  groups. 
Further,  the  interest  of  the  Subgroup  is  as  much  concerned  with  the  interactions  among 
these  fields  as  with  the  fields  themselves. 

C.  IDENTIFICATION  OF  THE  SUBGROUP’S  FIELDS  OF  INTEREST 

A  general  identification  of  the  Subgroup's  fields  of  interest  is  shown  in  the  attached 
road  map  entitled  "Evolutionary  Development  of  CALS,"  Figure  1,  which  shows: 
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1. 


Major  fields  contribute  to  CALS  in  the  same  way  as  these  fields  contribute 
to  any  other  computer-aided  technology.  These  include  data  bases, 
information  management,  contracting  procedures  and  standards.  The  road 
map  also  identifies  those  CALS-related  fields  that  involve  issues  which  are 
critical  to  the  Subgroup  (marked  *). 

2.  A  general  evolutionary  nature  of  all  CALS  fields  and  broad 
interrelationships  among  them. 

3.  The  involvement  of  CALS  in  the  different  phases  of  weapon  system 
development  from  setting  up  "Design  Influence  Algorithms"  to  evolving 
"New  Methods  of  Maintenance  and  Supply  Support." 

4.  The  transition  from  the  "what"  (data-based)  to  the  "how"  (knowledge- 
based)  logistic  systems. 

5.  The  need  for  a  logistics  information  flow  model  that  will  show  the  data 
sources  and  the  procedures  for  achieving  logistic  objectives  throughout  the 
entire  product  life  cycle. 

Figure  1  also  lists  possible  demonstration  projects  for  implementing  CALS.  These 
demonstrations,  like  the  individual  fields,  have  a  broad  range  —  extending  from 
investigating  "New  Logistic  Concepts"  to  "Benchmarking  New  CALS  Resources." 


D.  THE  RECURSIVE  NATURE  OF  CALS 

In  contrast  to  the  evolutionary  presentation  in  Figure  1,  the  CALS  concept  is 
intended  to  be  recursive,  i.e.,  it  will  be  applicable  from  design  to  manufacturing,  to  field 
support,  and  back  to  design  so  that  logistic  steps  can  be  inserted  at  any  point  in  the  life 
cycle  of  a  targeted  weapon  system.  Thus,  CALS  has  the  capacity  for  (a)  achieving 
immediate  logistic  benefits  during  retrofitting,  re-manufacturing  and  modernization;  as  well 
as  (b)  influencing  a  major  new  weapon  system  during  its  early  design  phase  so  that  benefits 
will  extend  over  the  total  developmental  and  operational  life  cycle  of  the  program. 

E.  SUBGROUP  FINDINGS  AND  RECOMMENDATIONS 

l.  Findings 

The  following  items  summarize  the  findings  of  the  Subgroup. 

1 .  Standards  efforts  are  needed  on 

a.  Identifying  the  overall  architectural  structure  for  CALS  --  especially  to 

allow  integrated  work  to  proceed  at  distributed  locations. 

b.  Identifying  a  set  of  standards  for  CALS  architecture. 

c.  Adopting  (early)  a  set  of  interface  standards. 

d.  Reviewing  the  present  FINDER  efforts  on  terms  and  headings,  which 
requires  more  attention  and  possible  redirection. 


2. 


Graphic  representation  effort  requires  attention  on  at  least  three  levels. 

a.  Digitizing  present  2D  drawings. 

b.  Converting  present  2D  drawings  to  digital  3D  representation. 

c.  Full  digital  structuring  of  3D  models. 

3.  Action  is  required  relative  to  projected  use  of  the  DDN,  especially  to 
develop: 

a.  A  time-phased  plan  that  will  show  the  extent  and  the  impact  of  CALS 
requirements  on  the  DDN  and  the  means  of  accommodating  these 
requirements. 

b.  A  policy  that  allows  contractors  early  access  to  the  DDN. 

c.  A  recognition  of  the  likely  need  for  contractors  —  and  possibly  DoD  --  to 

use  alternate  commercial  facilities,  and  the  means  of  accommodating 
this  need. 

4.  Action  is  needed  to  emphasize  the  consideration  of  supportability 
requirements  in  the  early  stages  of  design.  The  Subgroup  recommends  use 
of  the  term  supportability  in  accordance  with  DoD  Directives  5000.1  and 
5000.39,  rather  than  the  terms  R&M,  RM&L  and  RM&S. 

5.  An  acceptable  definition  or  specification  is  needed  for  a  basic  (kernel) 
logistics  system  which  should  be  a  line  item  in  the  Recommended  CALS 
Schedule  (line  number  3  or  4  is  suggested).  This  basic  system  should 
include: 

a.  A  functional  model  of  logistics  information  flows. 

b.  Algorithms  for  manipulation  of  the  logistics  information  in  Item  a. 

c.  A  logistics  workstation  for  handling  Items  a  and  b. 


2.  General  Recommendations 

The  Subgroup  strongly  recommends  the  following  four  programs,1  which  include 
demonstration  and  validation,  in  the  belief  that  substantial  progress  in  any  of  these  areas 
would  be  a  major  contributor  toward  achieving  key  CALS  objectives. 

a.  Creating  a  General  Logistic  Information  Model 

This  model  should  indicate  the  times  and  points  of  logistic  interaction  with  design 
and  manufacturing  in  carrying  out  a  generic  plan  for  weapon  system  development  and 
support  —  from  the  preconcept  (or  even  the  requirement/proposal  stage)  to  product 
disposition.  Consideration  should  extend  to  logistic  products,  available  logistic  data, 
formats,  modes  of  communication  and  interaction  and  a  definition  of  the  logistic  features 

lSee  the  Technical  Issues  Subgroup  Reports,  Volume  V  of  the  supporting  report  series,  for  details  on  these 
programs. 


that  are  desired  in  the  product  design.  The  Logistic  Information  Model  should  be  evolved 
by  continual  interaction  with  the  logistics  community  and  should  include  the  dynamic 
characteristics  of  the  logistic  process. 


b.  Developing  Design  Influence  Algorithms 

These  algorithms  should  provide  definitions  and  a  scale  for  measuring  and 
prioritizing  the  various  supportability  elements  (maintainability,  reliability,  testability, 
human  factors  and  other  logistic  objectives),  both  among  themselves  and  relative  to  non- 
logistic  features  of  the  product.  Particularly,  these  algorithms  must  be  available  and  be 
applied  during  the  early  stages  of  (1)  an  initial  design,  (2)  an  engineering  change,  (3) 
product  modernization,  or  (4)  item  re-manufacture.  Any  intent  to  review  a  proposed  design 
for  its  logistic  impact  after  its  first  design  review  will  be  too  late  to  be  effective. 

c.  Developing  a  Logistic  Workstation 

The  logistic  workstations  will  be  expected  to  support  logistic  interests  in  such  areas 
as  maintainability,  reliability,  testability  and  human  factors  (i.e.,  the  elements  of 
supportability)  in  the  same  way  that  a  computer-aided  design  (CAD)  computer  supports  the 
designer  in  the  areas  of  aerodynamics,  hydrodynamics,  structures,  hydraulics,  electronics 
and  kinematics  (i.e.,  the  elements  of  performance).  The  logistic  workstation  is  expected  to 
be  capable  of  manipulating  textual,  graphic  and  numberical  data  to  achieve  early  influence 
on  design  decisions.  Such  a  workstation  will  have  both  generic  software  and  its  own 
specialized  logistic  software  which  will,  among  other  things,  apply  algorithms  for  tradeoff 
analyses  and  employ  complex  logistic  rules  checking  to  ensure  a  supportable  design. 

d.  Developing  a  Kernel  Logistic  System 

The  kernel  logistic  system  combines  the  logistics  information  model,  the  design 
influence  algorithms  and  the  logistics  workstation  into  a  basic  integrated  system.  It  will  use 
the  logistic  workstation  and  its  algorithms  with  the  necessary  logistic  data  bases  (preferred 
parts;  lessons  learned  during  previous  design,  manufacturing  and  support;  cost  driving 
modes  and  levels;  and  dictionaries)  along  with  program  management  considerations  and 
priorities  to  achieve  an  integrated  basic  operational  logistic  system.  It  must  incorporate 
CALS  standards  and  be  compatible  with  general  CALS  requirements  and  other  interacting 
processes.  This  basic  or  kernel  system  must  be  interactive  on  a  real  time  or  a  near  real  time 
basis.  It  also  must  be  compatible  with  CALS  and  related  CAD/CAM  systems  at  both  the 


terminal  and  the  system  level  to  ensure  an  adequate  design  influence.  This  logistic  kernel 
concept  can  be  expanded  either  by  replication  or  by  expansion  to  meet  the  needs  for  broader 
interfacing  with  its  design  and  manufacturing  system  counterparts.  This  program,  which 
will  incorporate  the  basic  elements  of  Items  "a,"  "b,"  and  "c”  above,  should  be  entered  in 
the  Recommended  CALS  Schedule. 

3.  Technical  Issues 

This  section  provides  several  technical  issues  (items)  along  with  the  Subgroup’s 
comments.  These  items  require  a  critical  review  to  ensure  an  adequate  assessment 


Item  L  Total  Versus  Limited-Data  Needs 

Digitizing  the  total  data  requirements  of  DoD  and  possibly  those  of  its  prime 
contractors,  as  seen  by  its  suppliers,  would  be  complex,  costly  and  of  marginal  utility  —  as 
well  as  probably  beyond  the  present  state  of  the  art 

Comment:  Total  digital  data  systems  for  defense  logistics  are  well  off  into  the 
future  when  they  will  have  greater  utility.  Adequate  attention  should  be  given  to  a 
near  term  logistic  system  and  its  data  requirements  --  not  as  an  alternate  but  as  an 
essential  element  in  the  evolution  of  the  total  system.  Past  experience  with  large 
systems  shows  a  tendency  to  overcollect  data,  overdesign  products,  underestimate 
support  requirements,  underdevelop  CAM  and  overcontrol  the  various  functions. 
This  experience  calls  for  better  and  more  detailed  analysis  of  what  is  needed  to 
design  and  support  a  product. 


Item  2.  Loss  of  Proprietary  Data  Rights 

Contractors  fear  that  an  integrated  CAD/CAE/CAM/CALS  data  system  will  result  in 
loss  of  their  proprietary  data  rights. 

Comment:  The  ten  commonly  identified  separate  ILS  elements  and  the  presently 
separate  CAD/CAE/CAM/CALS  automation  efforts  provide  a  hierarchical  basis  for 
relieving  corporate  fears  over  loss  of  data  rights  while  setting  in  motion  the 
development  of  a  strong  CALS.  Technical  concepts  are  available  that  will  allow  the 
development  of  appropriate  CALS  access  control  procedures.  The  very  critical 
associated  CALS  data  management  architecture  needs  to  be  developed,  prototyped, 
and  tested. 

Note:  Items  1  and  2  discuss  the  technical  dimensions  of  the  issues  of 
implementing  allowable  data  access  and  avoiding  actual  loss  of  data.  The 
proprietary  rights  policy  issue  of  access  to  data  is  addressed  separately  by  the 
Policy  and  Legal  Constraints  Subgroup  and  reported  in  Volume  II  of  this  report. 


Standards  are  essential  to  a  successful  CALS.  In  particular,  standards  for  data 
interchange  between  heterogeneous  computer  systems  --  for  example,  standards  for  data 
formats,  communication,  and  data  bases  --  are  required. 

Many  of  the  required  standards  are  in  the  early  development  phase,  while  some  are 
more  complete.  Complete  standards  should  be  adopted  where  applicable,  standards  which 
are  near  completion  should  be  pushed,  and  preferred  practices  or  interim  specifications 
prepared  where  standards  are  lacking.  These  efforts  should  be  directed  through  existing 
standards  bodies  to  increase  CALS  leverage.  The  recommended  evolution  of  CALS 
standards,  as  well  as  the  choice  of  wide-interest  (if  not  yet  universal)  standards,  should 
serve  to  forecast  the  future  to  all  prospective  CALS  participants.  As  the  demand  for  CALS- 
compliant  capability  increases,  the  competitive  market  will  respond  with  products  at 
reasonable  cost 

Comment:  Standards  are  an  end  product.  Earlier,  they  are  proposals  for 
"unification"  of  protocols,  formats  and  procedures.  Many  benefits  of  standards  can 
be  achieved  by  preparing  and  calling  out  (1)  preferred  practices,  (2)  pre-standards, 
or  (3)  interim  standards.  These  documents  are  relatively  effective.  They  also  can 
be  developed  rapidly  and  they  are  less  costly. 


An  integrated  CALS  system  must  have  internal  standards,  such  as  standard  names, 
descriptors,  and  procedures.  These  should  be  common  across  the  Department  of  Defense. 

Comment:  A  naming  standard  is  underway  to  develop  a  list  of  approved  class 
words,  key  words,  and  modifiers  —  in  other  words,  a  classification  and  coding  of 
data  for  an  orderly  dictionary  to  support  the  IDS  System.  The  pre-standard  terms  in 
current  use  can  be  a  problem,  but  many  powerful  techniques  such  as  relational  data 
base  management  schemes  may  prove  to  be  at  least  a  partial  solution  to  this 
problem. 

In  order  for  typical  military  personnel  to  easily  use  and  understand  the  output  for 
automated  logistics  systems,  a  good  information  dictionary  is  needed.  An 
information  dictionary  identifies  symbols,  meanings  of  symbols,  the  relations 
between  symbols,  and  constraints  in  the  use  of  those  symbols. 

Currently  available  dictionaries  are  inadequate  in  these  basic  concepts  and  are 
incomplete  in  their  functions.  Recent  work  in  information  modeling  theory 
provides  a  basis  for  the  design  of  an  appropriate  information  dictionary,  but 
extensive  development  effort  is  needed  to  produce  an  appropriate  CALS 
information  dictionary. 

Note:  The  customary  reticence  of  commercial  enterprise  to  accept  standards  can  be 
turned  toward  enthusiastic  participation  by  careful  identification  of  the  status  of  each 
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standard  (see  first  paragraph)  and  equally  careful  description  of  the  context  of  use 
and  the  advantages  to  all  concerned  resulting  from  their  use  in  CALS  work. 


Item  5.  Design  Decision  Support 

A  total  information  concept  is  necessary  to  ensure  support  of  a  weapon  system  for 
decades  after  it  is  designed  (showing  the  design  assumptions  and  hypotheses  so  that 
subsequent  changes  do  not  re-insert  the  very  features  that  were  eliminated  from 
consideration  during  the  original  design.) 

Comment:  Detailed  records  of  design  appear  to  be  very  desirable  --  especially  for 
the  selected  design  and  for  the  thoroughly  analyzed  alternative  (rejected)  design 
features.  However,  annotated  log  entries  on  the  selected  design  and  many  of  the 
rejected  features  may  be  adequate  records  of  the  disposition  if  the  log  provides 
adequate  guidelines  for  reconstructing  the  basis  for  the  original  decision. 


Item  6.  Embedded  Processors  and  CALS 

Developments  in  computer-aided  technologies  make  possible  the  use  of  embedded 
processors  as  sources  of  essential  logistic  data.  These  embedded  processors  differ  from 
the  usual  CAD/CAM/CALS  computers  to  such  a  degree  that  the  effective  use  of  their  output 
is  a  challenge  to  the  CALS. 

Comment:  The  rapid  development  and  expanded  use  of  embedded  processors  is  a 
valuable  aid  to  anticipating  logistic  needs  and  to  impressing  these  needs  on  the 
conceptual  design  of  a  weapon  system.  Properly  considered,  these  computers  offer 
a  welcome  potential  for  more  complete,  more  accurate  and  more  timely  logistics 
data  gathering,  reduction  and  use. 


Item  7.  CALS  During  .Surge 

The  CALS  must  be  more  flexible  than  is  suggested  by  its  present  strong  focus  on  a 
seemingly  idealized  early  attainment  of  its  ambitious  technical  and  organizational  goals. 

Comment:  Some  logistic-related  computer-aided  technologies  were  "given  some 
consideration"  during  recent  surge  (limited  mobilization)  studies.  CALS  issues 
must  be  strengthened  and  set  forth  more  convincingly  in  order  to  get  more  serious 
consideration  during  such  surge  studies.  A  proven  CALS  capability  can  be  a 
valuable  decision-aiding  tool  during  future  exercises. 


The  problems  of  working  with  both  conventional  and  a  variety  of  digitized  (CAD) 
drawings  in  the  same  product  program  suggest  the  need  for  a  large-scale  conversion  of 
present  drawings  to  digital  format  and  their  accommodation  to  other  automated 
requirements. 

Comment:  Current  technology  and  practice  expresses  all  parts  specifications  on 
the  medium  of  an  engineering  drawing  designed  solely  for  human  interpretation. 
Future  requirements  are  for  this  part  definition  to  be  captured  electronically  for  ease 
of  communication,  for  archival  integrity  and  for  interpretation  by  computer. 

Digital  scanning  of  existing  drawings  allows  the  drawing  to  be  electronically  stored 
and  transmitted  over  communication  channels  and  reproduced  at  the  other  end. 
Current  scanners,  data  compression  techniques,  laser  storage  systems,  and  laser 
printers  provide  most  of  the  necessary  technical  tools  required  to  effectively  utilize 
digitized  drawings. 

Present  part  models  are  expressed  as  2D  wireframe,  3D  wireframe  and  3D  surface 
geometric  models.  Each  of  these  representations  is  incomplete  in  terms  of  the  total 
information  content  needed  for  analysis  or  for  automated  manufacturing  planning. 
Solids  models  are  seen  to  be  the  approach  to  give  the  required  "completeness"  to  the 
product  model. 

CALS  must  recognize  this  diversity,  accommodate  the  technological  trends  and  plan 
for  the  effective  utilization  of  these  various  forms  of  data  models.  New  technology 
developments  should  be  supported  and  related  standards  activity  encouraged. 
Validation  techniques  should  be  created  to  check  the  integrity  of  data  received  by 
DoD  in  any  of  these  forms. 

Recognizing  there  will  be  a  variety  in  the  forms  for  digital  representation  of  product 
model  data,  the  CALS  program  should  encourage  the  creation  of  translators  to 
change  the  part  model  from  one  particular  digital  form  to  another  form. 

In  the  order  of  sophistication,  completeness  and  complexity,  these  forms  arc: 

Digitally  Scanned  Drawing 
2D  Wireframe  Model 
3D  Wireframe  Model 
Surfaced  Model 
Solids  Model. 

Translators  to  convert  a  more  sophisticated  model  to  a  lesser  sophisticated  model  will  be 
relatively  easy  to  develop.  The  reverse  will  be  far  more  difficult  However,  it  will  be  these 
translators  that  will  be  far  more  valuable  to  DoD  over  the  life  span  of  the  archive  data  files, 
for  they  will  enable  an  easy  transition  to  new  technology  tools  for  logistics  support. 
Example  translators  might  include  either  2D  or  3D  Wireframe  Model  Creation  from 
scanning  of  an  engineering  drawing. 


All  of  the  Subgroup's  fields  of  interest  --  including  their  related  issues  —  are 
candidates  for  future  implementation  as  artificial  intelligence-based  or  expert/knowledge- 
based  systems.  The  lack  of  needed  knowledge  or  technology  should  not  delay  logistics 
developments  leading  toward  knowledge-based  systems  so  long  as  the  possible  later 
transition  from  data-based  to  knowledge-based  system  operation  is  given  appropriate  early 
attention. 


F.  LIST  OF  THE  SIX  STUDY  PAPERS  CONSIDERED 
BY  THE  SUBGROUP2 

1.  "Supportability  (£)  Program  -  Appendices,"  Erich  Hausner,  Lockheed,  November 

1983  (58  pages). 

The  contract  report  presents  a  model  for  relating  supportability  (£)  and  life  cycle 
cost,  giving  an  interface  matrix  and  the  needed  computations. 

2.  "Definitions  of  Terms  for  Supportability,"  (Military  Standard  721C-XXX, 
Proposed)  Erich  Hausner,  Lockheed,  November  1983  (137  pages). 

This  report  includes  107  pages  of  supportability  definitions  plus  abbreviations  and 
Design-to-Requirements  (SDTR)  codes. 

3.  "Future  Functional  Allocation  Between  Govemment/Contractor,"  Kurt  Molholm 
and  Bill  Presker,  Defense  Logistics  Agency,  October  1984  (4  pages). 

This  report  considers  several  aspects  of  turn-key  vs  more  detailed  allocation  of 
responsibility  in  several  areas  of  logistic  concern,  especially  in  the  spare  parts  field. 

4.  "Role  of  Experience  Data  in  Logistics  Planning,"  G.  L.  Foreman,  Hughes,  October 

1984  (24  pages). 

The  report  identifies  sources  of  existing  logistic  data,  its  assessment  and  its  use. 
Also  included  are  comments  on  evaluation  of  a  user's  R2M  procedures. 

5.  "Unified  Data  Base  for  Logistics  Information  -  A  DoD  Statement  of  Work,"  (via) 
Fred  Macey,  Lockheed,  September  1984  (17  pages). 

This  contract  work  statement  covers  four  phases  of  UDB  activity:  technology 
development;  test  and  demonstration;  evaluation;  and  transition. 

6.  Five  Sets  of  Charts  Showing  CALS-Related  Data/Information  Flows  (nine  pages, 
see  next  page). 


2For  more  information  concerning  these  papers,  contact  the  Institute  for  Defense  Analyses. 


The  exhibits  listed  below  show  various  approaches  and  interpretations  of  logistic 
information  functions  at  different  points  in  the  product  life  cycle. 


CALS-RELATED  DATA/INFORMATION  FLOW 
DURING  THE  LIFE  CYCLE  OF  A  DEFENSE  SYSTEM 


Tide 

Sheets 

Author/Source 

Date 

CALS  Supportability  -  a  New 
Dimension  in  Design 

3- 

24"x30" 

E.  Sausner 
(Lockheed) 

- 

CALS-Related  Functions  During 
the  Life  Cycle  of  a  Weapon 

System 

1  - 

12"x72" 

“ 

Generic  Life  Cycle  Representation 
for  Defense  System  Acquisition 

3- 

12"x30" 

Saunders 

1984 

Engineering  and  Test  Flow 

1  - 

4"xl2" 

- 

- 

Acquisition  Life  Cycle  Technical 
Activities 

1- 

24"x36” 

Booz,  Allen 
&  Hamilton 

1984 

LIST  OF  REPORTS  PREPARED  BY  THE 
TECHNICAL  ISSUES  SUBGROUP 


CONTENTS  AND  SUMMARY 


"Shared  Data  -  Key  to  Achieving  Improved  Productivity 
Through  Computer-Aided  Logistics  Support." 

John  Willis  and  Darrell  Cox,  Rockwell  International, 

October  1984 . . . 17 

The  report  discusses  the  Integrated  Design  Support  System  (IDS)  study  as  it  is 
applied  to  the  B-1B  bomber.  It  further  considers  other  information  systems  and 
neutral  data  bases,  and  touches  on  the  Air  Force's  Logistics  Technical  Support 
Center  (TSC).  Nine  graphics  exhibit  pages  summarize  the  report  concepts. 


"Flow  of  Information  in  Defense  Programs  -  Employing  a 
General  Logistics  Information  Model." 

Darrell  Cox,  Rockwell  International,  and  George  Beiser,  IDA, 

October  1984 . 34 

The  report  presents  a  preliminary  concept  for  showing  flow  of  information  from  a 
normal  repository  through  a  typical  computerized  process  and  back  to  a  repository. 
It  considers  the  total  life  cycle  of  a  product;  however,  the  figures  themselves  are 
incomplete. 

"Scope  of  CALS." 

(via)  Fred  Macey,  Lockheed  Corporation,  October  1984 . 41 

The  report  poses  several  questions  about  the  scope  of  CALS  and  offers  a  strategy 
for  its  implementation.  It  presents  time-based  diagrams  showing  the  percentages  of 
automation  in  (1)  drawing  preparation  and  (2)  parts  list  preparation  from  1960  to 
today,  and  projects  estimates  to  the  year  2000.  The  report  further  presents  a  chart 
showing  the  role  of  technical  management  in  automated  design,  procurement, 
manufacturing,  testing  and  logistics. 


"Computer-Aided  Logistics  Support." 

Eric  Hauser  and  Bob  McCall,  Lockheed  Corporation,  October  1984 . 50 

The  report  emphasizes  payoff  of  CALS  as  it  relates  to  both  industry  and 
government  in  the  near  term  and  the  long  term.  It  considers  the  incentives  and  the 
barriers  to  expanding  CAD  to  include  supportability. 


"Issue  -  Support  of  Contractor/DoD  Decision  Processes. 
G.  L.  Foreman,  Hughes,  October  1984 . 


58 


The  report  addresses  the  decisionmaking  process  in  terms  of  (1)  data  changes,  (2) 
data  additions,  and  (3)  the  remaining  unchanged  data.  It  stresses  the  problems  of 
maintaining  an  audit  trail  that  considers  both  the  results  of  a  decision  as  well  as  the 
rationale  for  making  the  decision. 

"Limits  on  DoD  Action." 

George  W.  Fredricks,  IBM,  October  1984 . 63 

The  report  discusses  new  (as  opposed  to  adapting  present)  capabilities  of  CALS.  It 
addresses  Standards,  Implementation  Networking,  Security,  Flexibility,  and 
Proprietary  Information. 


"Points  for  Highlighting  in  the  CALS  Program." 

Ernest  Glauberson,  U.S.  Navy,  NAVSEA,  October  1984 . 73 

The  report  considers  such  problems  as  overcollecting  data,  overdesigning  products, 
and  underestimating  support.  It  discusses  the  use  of  expert  systems  and  process 
models  in  the  solution  of  such  problems.  It  further  distinguishes  between  the  need 
for  unification  of  protocols,  formats,  etc.,  and  the  later  establishing  of  standards. 


"CALS  Demonstrations:  Process  and  Recommended  Areas." 

Ray  Bourn,  IBM,  September  1984 . 84 

The  report  recommends  having  at  least  two  contractors  address  the  same  technical 
issue  at  the  same  time  in  demonstrations  using  subcomponents  of  a  weapon  system 
as  a  test  vehicle.  It  suggests  areas  for  emphasis  and  sets  forth  a  three-phase  plan 
for  implementation.  It  also  suggests  areas  for  future  CALS  research. 


"The  Computer-Aided  Logistics  Support  (CALS)  Project" 

William  Tunnicliffe,  Graphic  Communications  Association . 88 

The  report  presents,  in  text  and  figures,  the  scope  of  proposed  Handbook  84-101 
and  the  total  set  of  graphic  standards  involved.  It  also  presents  a  conceptual  outline 
of  publications  and  the  relationships  of  the  graphics  processes  and  standards. 

"Technology  and  Standards  Issues  Related  to  Computer- 
Aided  Logistics." 

Robert  J.  Hocken,  National  Bureau  of  Standards,  September  1984 . 98 

The  report  discusses  the  set  of  standards  that  is  needed  for  CALS,  including  those 
for  communications,  graphics,  text,  product  definition,  and  data  bases.  It  also 
presents  a  set  of  recommendations  that  addresses  both  needs  and  plans  for 
implementation  in  this  area. 


1 1.  "IGES:  A  Key  Interface." 

Bradford  Smith,  National  Bureau  of  Standards,  October  1984 . 107 

The  report  describes  the  procedures  that  have  been  used  to  develop  the  IGES 
standard  to  date  and  lists  the  vendors  that  have  participated  in  public  inter-system 
exchange  of  data  on  an  illustrated  test  part. 

12.  "Foreman’s  Concept  'A'  -  Logistics  Tool:  Creation  vs  Use." 

G.  L.  Foreman,  Hughes,  February  1983 .  122 

The  report  presents,  in  text  and  chart  form,  the  three  levels  of  logisticians  and  their 
respective  involvements  during  the  different  phases  of  the  product's  life  cycle. 

13.  "Access  Control,  Management  and  Integrity  of  Information." 

Robert  R.  Brown,  Hughes,  October  1984 . 125 

The  report  discusses  the  importance  of  the  listed  topics  and  present  limitations  in 
our  ability  to  handle  these  items.  It  lists  three  factors  that  are  important  in  assuring 
integrity  of  CALS  information. 

1 4.  "ANSI  Data  Element  Dictionary." 

Robert  R.  Brown,  Hughes,  November  1984 . 129 

The  report  reviews  the  two  recent  ANSI  standards  in  this  field  that  should  be 
applicable  to  CALS  and  finds  that  they  are  inadequate.  The  report  states  that  many 
of  the  computer  tools  needed  to  solve  the  data  dictionary  problems  are  available  but 
that  much  work  needs  to  be  done  to  achieve  a  solution. 

1 5 .  "Network  Example  -  Seven  Layers  of  the  International 
Standards  Organization  (ISO)  Data  System  Model." 

Bradford  Smith,  National  Bureau  of  Standards,  1984 . 131 

A  series  of  tables  shows  the  seven  layers  of  the  ISO  model  along  with  the  function 
of  each  layer.  It  also  shows  the  General  Motors'  MAP  emerging  factory  standard 
and  the  approval  status  of  ten  major  graphics  and  data  base  standards. 

16.  "Gencode*/SGML  Strengths  in  the  Text  Processing  Environment." 

William  Tunnicliffe,  Graphic  Communications  Association, 

December  1984 . 145 

This  is  a  three-part  report  that  summarizes  CALS  recommendations  in  the 
GENCODE*/SGML  standard  areas  and  presents  the  development  status  for  these 
s.andards.  The  figures  show  the  relationships  between  the  various  standards  and 
the  process  steps  that  relate  to  these  standards. 

17.  "Standards  Development  Organizations  Structure 

and  Participating  Personnel." . 171 

This  two-part  report  (17A,  17B)  is  a  complete  review  of  ANSI  and  ISO  groups  and 
individuals  working  on  standards  development  in  fields  of  interest  to  CALS. 
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17 A.  "International  and  National  -  ISO  and  ANSI  -  Standards 
for  Manufacturing." 

Bradford  Smith,  National  Bureau  of  Standards,  December  1984. 


The  report  discusses  standards  activities  in  tooling,  fabrication  and  communications 
for  manufacturing.  It  considers  the  primary  interface  standards  needed  for 
interchangeability  of  manufacturing  data.  The  report  also  gives  the  status  of 
pending  standards  actions  in  this  field  and  lists  the  organizations/individuals 
participating  in  the  effort. 

17B.  "International  and  National  -  ISO  and  ANSI  -  Standards 
for  Information  Processing." 

William  Tunnicliffe,  Graphic  Communications  Association, 

December  1984 . 184 

This  is  an  outline  of  the  standards  efforts  that  are  underway  in  the  information 
processing  field.  (NOTE:  Information  about  a  60-page  compilation  of  standards 
organizations  and  their  structure,  along  with  the  active  individuals  and  their 
affiliations,  can  be  obtained  from  IDA.) 

18.  "Supportability  Implementation  in  the  Acquisition  Process." 

Bob  McCall,  Lockheed,  November  1984 . 187 


This  visual  presentation  material  develops  the  concept  of  supportability  as  a  very 
broad  logistics  objective.  Inasmuch  as  Reliability  (R),  Maintainability  (M)  and 
Support  have  been  identified  as  major  considerations  in  the  front-end  of  product 
design  analysis,  this  report  emphasizes  that  the  major  issue  is  design  for 
Supportability  (£).  Recent  research  has  pointed  out  that  supportability  can  be 
related  directly  to  sortie  generation  in  the  case  of  combat  aircraft. 

"The  Logistics  Information  Model." 

The  Technical  Issues  Subgroup,  November  1984 . . . 213 


The  report  describes  the  need  for  identifying  and  characterizing  the  logistics 
information  sets  and  their  flows  during  the  full  life  cycle  of  a  variety  of  defense 
products.  It  recommends  an  implementation  plan  for  setting  up  such  a  model, 
listing  individual  tasks,  a  calendar  schedule  and  an  estimated  funding  level  for 
achieving  its  objective. 

"Developing  Design  Influence  Algorithms  for  Logistics." 

The  Technical  Issues  Subgroup,  November  1984 . 220 


The  report  describes  the  need  for  logistics  algorithms  that  can  be  used  effectively  by 
the  product  designer  early  in  the  design  process.  A  list  of  recommended  tasks  is 
provided  but  the  project  is  viewed  as  continuously  developing,  thus  no  time 
schedule  or  level  of  funding  is  given. 
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"The  Logistics  Workstation." 

The  Technical  Issues  Subgroup,  November  1984 . 224 

The  report  points  out  the  need  for  a  workstation  that  is  functionally  comparable,  in 
the  logistics  field,  to  the  present  CAD  workstations  in  the  design  engineering  field. 
It  lists  the  main  characteristics,  benefits  and  points  for  early  application  of  such  a 
facility  and  it  provides  recommended  tasking  and  time  scheduling  for  the  project 


"The  Kernel  Logistics  Information  System." 

The  Technical  Issues  Subgroup,  November  1984 . 228 

The  report  addresses  the  concept  of  deploying  computer  automation  into  a  highly 
distributed  data  system,  giving  the  logistics  facility  a  basic  system  structure.  It  lists 
the  major  tasks  for  implementing  this  concept  and  it  recommends  a  time  scale  and 
tasks  for  immediate  funding. 

"Initiatives  in  Automated  Technical  Information." 

IBM,  June  1984 . 232 

A  series  of  charts  presents  a  synopsis  of  a  meeting  on  ongoing  and  planned 
activities  to  automate  the  flow  of  technical  information  at  the  IBM  Federal  Systems 
Division  facility  in  Manassas,  Virginia. 
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SHARED  DATA  - 

KEY  TO  ACHIEVING  IMPROVED  PRODUCTIVITY  THROUGH 
COMPUTER  AIDED  LOGISTIC  SUPPORT 

A.  INTRODUCTION 

The  objective  of  this  paper  is  to  explore  the  aspects 
of  logistic  support  data  requirements  for  an  emerging  weapons 
system  and  to  suggest  a  logical  approach  for  transition 
from  current  information  support  systems  of  today  to  shared 
data  structured  systems  of  tomorrow. 

The  B-1B  bomber  was  selected  as  a  typical  example 
of  an  emerging  weapons  system  for  this  discussion  because 
of  its  position  in  the  development  and  deployment  phase. 
Logistic  data  bases  that  are  currently  being  developed 
will  support  this  weapon  system  well  into  the  next  century. 

The  current  functional  and  informational  data  models  for 
these  logistic  data  bases  are  derived  from  a  conceptual 
design  study.  This  study,  identified  as  the  Integrated 
Design  Support  System  (IDS),  is  required  for  the  development 
of  an  advanced  engineering  support  information  system. 

The  conceptual  study  was  funded  by  the  U.S.  Air  Force  Wright 
Aeronautical  Laboratory.  The  models  developed  under  this 
study  were  focused  on  sustaining  engineering  support  to 
B-1B  design,  manufacturing,  depot  and  field  support  activities 
and  are  generic  to  many  emerging  weapons  systems. 

B.  THE  PRESENT  (AS  IS)  LOGISTIC  SUPPORT  DATA  ENVIRONMENT 
Considerable  industry  and  government  attention  has 

been  focused  on  both  the  development  and  integration  of 
automated  business  systems  and  on  the  development  of  computer- 


aided  engineering  systems.  Little  effort,  however,  has 
been  applied  to  the  integration  of  computer-aided  engineering 
systems  or  to  the  design  of  systems  to  acquire,  manage, 
and  communicate  graphical,  alphanumeric,  and  textual  data 
in  various  combinations.  Research  and  development  work 
has  been  performed  on  generic  data  base  management  technology 
under  the  IPAD*,  ICAM,  and  ATI  programs,  but  this  technology 
has  not  been  exploited  on  a  broad  level  for  the  development 
and  deployment  of  major  weapon  systems. 

A  wide  range  of  technical  support  activities  provide 
product  technical  data  services  from  conceptual  design 
through  manufacturing,  weapon  system  operations,  and  product 
retirement.  A  top  level  schematic  of  organizational  technical 
support  activities  for  the  B-1B  aircraft  system  development 
program  is  shown  in  Figure  1.  The  diagram  is  intended 
to  depict  sustaining  engineering  support  activities  that 
use  engineering  data  directlv  such  as  manufacturing  material 
review,  repair,  depot  repair  and  design  modifications. 

It  should  be  noted  that  significant  secondary  uses  of  technical 
support  data  are  not  shown  in  the  diagram  such  as  traini^  . 
maintenance  provisioning,  and  operations  mission  analysis 

Current  emphasis  by  both  the  government  and  industry 
is  in  the  development  of  organizational  rather  than  data 
driven  systems.  In  the  development  of  a  weapon  system, 
the  traditional  technical  support  data  bases  that  are  passed 
on  to  the  contracting  agency  are  engineering  drawings, 
specifications,  and  technical  orders  for  maintenance  support. 
The  remaining  technical  data  bases  that  reside  with  the 

*IPAD  -  Integrated  Programs  for  Aerospace  Vehicle  Design  -  NASA 
ICAM  -  Integrated  Computer  Aided  Manufacturing  -  USAF 
ATI  -  Automated  Technical  Information  -  USAF 
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contractor  are  significant.  An  example  of  structural  technical 
support  data  bases  for  the  B-1B  is  shown  in  Figure  2. 

It  should  be  noted  that  a  majority  of  digital  and  graphic 
data  bases  are  considered  private.  These  data  bases  are 
controlled  by  design  and  analysis  support  organizations 
and  are  not  maintained  as  official  released  data. 

There  are  a  number  of  inplaoe  and  emerging  logistic 
informational  systems  both  at  contractor  and  government 
facilities.  An  example  of  key  Rockwell  and  government 
logistic  systems  that  utilize  or  manipulate  information 
is  shown  in  Figure  3.  Today's  technical  support  systems 
are  generally  hierarchical  in  nature,  are  transaction  driven, 
and  many  operate  in  a  batch  environment.  Data  resides 
in  a  heterogeneous  computer  environment  and  are  generally 
non-communicati ve  between  dissimilar  computer  systems. 

Specific  problems  and  issues  with  today's  heterogeneous 
logistic  support  information  system  environment  are  discussed 
in  the  following  paragraphs. 

While  technical  computer  innovations  and  data  system 
automation  are  progressing  at  an  accelerated  rate,  integration 
through  shared  data  is  progressing  slowly. 

Information  systems  have  not  been  developed  from  a 
data  driven  approach,  but  rather  from  an  organizational 
or  application  driven  approach.  Present  information  systems 
serve  discrete  user  needs.  Redundant  product  support  data 
must  be  maintained  or  recreated  in  many  data  bases. 

Neutral  data  formats  are  being  developed  that  address 
geometric  and  textual  data  communications  between  computers 
and  graphic  terminals.  Two  such  systems  are  IGES  and  GENCODE. 
Development  of  these  systems  is  currently  evolving.  Technology 
that  is  currently  lagging  involves  heterogeneous  data  control 
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ard  manipulation.  This  problem  is  partly  due  to  the 
computer  vendors  and  the  competitive  nature  of  industry  and 
government  functional  organizations. 

In  the  development  of  a  weapons  system,  data  is 
acquired  in  the  form  of  discrete  CDRL's  (Contract  Data 
Requirement  List).  Even  though  there  is  a  determined 
relationship  between  many  if  not  all  of  the  data 
deliverables,  such  as  drawings,  specifications,  and 
technical  orders,  the  data  is  delivered  to  government 
organizations  and  stored  as  separate  data  systems.  These 
information  systems  include  paper,  micro-fiche  and  magnetic 
storage  mediums.  Even  though  transition  to  digitized  data 
bases  is  occurring,  the  prevailing  mentality  of  information 
management  remains  in  the  paper  medium. 

Present  government  automated  logistic  technical  data 
base  development  programs  (EDCARS*-computer  based  drawings, 
and  ATOS-automated  tech  orders)  do  not  address  the  aspects 
of  shared  data  outside  of  their  own  application.  Furthermore 
government  logistic  support  organizations  have  not  developed 
overall  strategies  for  dealing  with  new  digitized  design 
and  analysis  data  bases  that  are  required  for  long  term 
logistic  support  of  major  weapon  systems.  Examples  of 
such  data  bases  are  referenced  in  Figure  2. 

Current  trends  encouraged  by  the  Air  Force  Logistics 
Command  to  consider  the  logistic  implications  of  a  weapon 
system  at  design  time  can  be  expected  to  continue.  However, 

*EDCARS  -  Engineering  Data  Collection  and  Retrieval 

System  -  USAF 

ATOS  -  Automated  Technical  Order  System  -  USAF 

*EDCARS  Engineering  Data  Computer  Assisted  Retrieval 
System  USAF. 


the  attitude  of  both  the  customer  and  the  system  designer 
must  change  for  this  to  be  the  case.  The  customer  (the 
Air  Force  in  this  instance)  must  not  only  encourage  the 
contractor  to  design  supportability  into  the  system,  but 
must  also  be  ready  to  fund  the  additional  effort  this  requires. 
Once  chartered  by  the  conditions  of  the  contract,  the  system 
designer  must  be  as  creative  and  as  innovative  as  possible 
in  anticipating  the  future  requirements  of  the  weapon  system, 
not  only  from  the  operational  point  of  view,  but  from  the 
damage  repair  and  maintenance  point  of  view  as  well,  a 
not  inconsequential  challenge  considering  the  complexity 
and  sophistication  of  today’s  weapons. 

The  computer  offers  the  maximum  opportunity  to  support 
the  system  designer  in  accomplishing  ambitious  design  goals. 
Hardware  manufacturers  can  be  expected  to  deliver  increasingly 
sophisticated  tools  for  storage,  computation  and  manipulation 
of  data.  Trends  in  firming  up  programmed  engineering  design 
rules  and  processes  by  means  of  reducing  them  to  PROMs 
and  EPROMs  and  offering  this  capability  at  the  touch  of 
a  key  will  also  continue.  Software  houses  will  continue 
to  provide  the  engineer  with  an  increasingly  capable  array 
of  data  base  management  systems  designed  for  more  flexibility 
at  less  cost  with  more  reliability. 

"Where  is  the  challenge,  then?"  one  may  ask.  In  a 
word,  the  challenge  is  in  the  data.  The  management  of 
this  critical  asset  poses  a  challenge  equal  to  the  technology 
which  conceived  it.  The  subtlety  of  the  challenge  is  that 
few  people  intuitively  appreciate  the  magnitude  and  complexity 
of  the  data  problem. 

The  system  designer  may  perceive  the  major  problem 
to  be  addressed  as  a  computational  problem  and  only  incidentally 
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a  data  problem.  After  all,  shouldn't  the  data  be  regarded 
as  a  given?  From  the  individual  designer  point  of  view 
the  data  might  be  regarded  as  something  solely  personal 
and  individual  but  a  moment's  reflection  dispels  this  notion. 
The  conventional  view  has  it  that  when  the  design  data 
is  firmed  up  it  can  be  released  and  configuration  management 
imposed  -on  it.  This  has  worked  reasonably  well  for  the 
manufacturing  and  downstream  functions  of  the  contractors 
and  subcontractors,  before  delivery  of  the  system  to  DoD, 
who  must  now  service,  maintain  and  repair  the  system  in 
an  operational  environment.  Many  years  or  even  decades 
later,  after  numerous  repairs  and  modifications  have  been 
implemented  on  the  system,  the  original  design  data  may 
have  been  lost,  the  original  manufacturer  may  no  longer 
be  in  the  same  business,  and  design  assumptions  and  hypotheses 
may  have  to  be  guessed  at. 

Will  this  situation  suffice  for  the  weapons  systems 
of  today  as  these  systems  age  in  operational  service? 

The  computer  offers  the  mechanism  with  its  ability  to  store 
and  manipulate  vast  amounts  of  data  with  acceptable  speed. 

Data,  defined  at  the  attribute  class  level,  documented 
as  supporting  a  particular  function  in  the  data  model, 
and  available  from  a  shared  source  on  a  node  of  a  heterogeneous 
network  utilizing  secure  communications  seems  to  offer 
a  necessary  and  required  asset,  one  which  is  lacking  in 
today's  logistics  environment. 

C.  FUTURE  (TO  BE)  LOGISTIC  SUPPORT  INFORMATION  SYSTEMS 

The  ''To  Be”  world  addressed  by  the  IDS  system  envisions 
a  scenario  similar  to  the  one  described  above,  and  work 
is  starting  on  the  disciplining  of  the  data.  The  current 
world  seems  to  be  "forms”  driven,  there  is  a  form  for 
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everything,  and  everything  has  its  form.  Forms  are  a  necessity 
in  a  paper  environment.  How  else  to  assure  the  completeness 
of  the  data  or  its  location  in  the  manual  filing  systems 
of  yesterday  (and,  unfortunately,  of  today)?  The  electronic 
world  can  be  forms  independent  and  offer  flexibility  undreamed 
of  in  a  paper  based  media.  But  much  needs  to  be  accomplished 
in  the  science  (or  art)  of  managing  the  data  before  this 
becomes  a  reality.  A  naming  standard  for  the  technical 
data  world  of  tomorrow  is  just  now  being  formulated.  It 
includes  developing  a  listing  of  approved  class  words, 
key  words  and  modifiers,  in  other  words,  classification 
and  coding  of  data.  The  use  of  this  device  will  attempt 
to  bring  order  in  the  dictionary  as  attributes  and  entities 
are  gathered  across  the  vast  range  of  functional  activities 
served  by  the  (IDS)  system. 

The  key  to  achieving  future  DoD  productivity  in  weapon 
system  support  is  in  the  development  of  data  driven  rather 
than  organizational  driven  systems.  Future  logistic  informa¬ 
tion  systems  need  to  address  the  following  issues: 

o  Reconfiguration  of  contractor  and  DoD  structure  and 

organizational  policies 

o  User  and  application  designed  ”ad  hoc”  queries 
o  Total  product  support  rather  than  individual  CDRL's 

o  Heterogeneous  data  base  managers  on  heterogeneous 

computers 

o  Hardware-oriented  data  base  machines 

o  Versatile  generative  combinations  of  data  elements 
o  Effective  classification  and  coding  schemas 

The  development  of  computer  aided  logistics  support 
should  be  an  orderly,  evolutionary  process  with  appropriate 
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DoD  component  service  policy  guidance  and  successful  resolution 
of  key  technical  issues.  The  policy  will  be  required  to 
address  three  key  issues; 

1.  Commitment  to  a  broad  program  architecture  that  will 
permit  development  in  a  systematic  manner. 

2.  The  integration  of  developing  data  base  management 
technologies  into  rapidly  maturing  CAD/CAM/CAE  technologies. 

3.  The  establishment  of  requirements  for  future  weapon 
system  designs  to  support  automated  logistics  data 
collection  activities  necessary  for  emerging  support 
concepts . 

Key  technical  issues  must  be  addressed  through  the 
extension  of  evolving  information  system  concepts  —  and, 
in  some  instances,  new  concept  developments.  Influencing 
of  the  standards  environment  to  achieve  a  compatible  hierarchy 
of  standards  is  necessary  for  handling  the  full  range  of 
logistics  data  in  digital  format. 

A  key  to  the  success  of  computer  aided  logistics  support 
is  the  ability  to  develop  an  information  model  for  logistics. 
Today,  each  logistics  data  requirement  is  like  looking 
at  the  weapons  system  through  a  knot  hole  —  not  seeing 
the  whole  and  not  having  data  relatable  to  other  data. 

Data  base  concepts  will  be  required  to  accommodate  both 
man/machine  and  machine/machine  users.  Data  storage  has 
to  be  viable  for  the  life  of  the  weapons  system  (30  years 
plus).  The  integration  of  data  types,  (i.e.  text,  graphics, 
tables,  math  models,  etc.)  has  to  be  achieved  to  preserve 
information  context.  Information  management  concepts  for 
access  and  integrity  control  throughout  a  wide-spread  network 
of  users  will  present  a  challenge. 
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Logistics  data  can  be  expected  to  transition  from 
information  (the  "what" )  oriented  to  knowledge  (the  "how") 
in  recognition  of  the  capability  of  capture  of  an  embedded 
knowledge  base  in  the  design  and  manufacture  of  a  weapons 
system  and  in  the  deployment  and  operation  of  weapons  systems. 
The  embedded  knowledge  will  be  more  accessable  as  computer 
assistance  becomes  inherent  in  the  processes  that  build 
and  operate  future  weapon  systems. 

The  first  tangible  product  in  computer  aided  logistics 
support  is  the  deployment  of  a  "kernel"  logistics  information 
system.  Such  a  system  will  require  a  concept  for  a  logistics 
workstation  —  using  a  low  cost  existing  terminal,  and 
a  design  of  a  logistics  data  base.  Once  the  "kernel"  system 
is  deployed,  new  analytical  software  will  evolve  for  every 
element.  This  software  will  provide  capability  beyond 
currently  available  tools  as  it  incorporates  access  to 
new  data  base  resources. 

Government  systems  will  require  upgrade  to  accept 
digital  format  logistics  data.  New  contracting  vehicles 
will  be  required  to  define,  specify  and  receive  digital 
logistic  products. 

The  above  is  at  best  only  a  glimpse  into  the  new  frontiers 
that  can  be  achieved  through  computer  aided  logistic  support. 

A  time  phase  road-map  of  capability  with  some  key  technical 
demonstrations  is  shown  in  Figure  4.  This  is  intended 
to  show  general  direction  and  is  not  a  specific  plan. 

What  is  described  in  Figure  3  is  a  major  undertaking  involving 
coordination  throughout  DoD  and  the'defense  industry. 
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D.  INTEGRATED  DESIGN  SUPPORT  SYSTEM  (IDS)  TECHNOLOGY  WEDGE 
The  U.S.  Air  Force  Human  Resources  Laboratory  (HRL )  and 
a  coalition  of  USAF  and  technology  subcontractors  headed  by 
Rockwell  International  are  currently  developing  and 
prototyping  an  advanced  information  technology  system  called 
IDS. 

The  objective  of  the  IDS  program  is  to  design,  develop, 
construct  and  demonstrate  a  prototype  information  management 
system  that  will  provide  capability  to  efficiently  capture, 
manage,  and  distribute  key  digital  technical  data  across  the 
entire  life  span  of  major  Air  Force  weapons  systems.  (See 
F igure  5  . ) 

The  major  IDS  program  challenges  and  goals  are 
summarized  below: 

(1)  To  deelop  a  prototype  IDS  system  that  will  demonstrate 
integration  of  state-of-the-art  and  emerging  technology 
to  manage  technical  data  in  a  heterogeneous  computer 
and  functional  environment. 

(2)  To  develop  engineering  functional  and  information 
models  that  provide  a  complete  understanding  of  data 
and  activity  structure  from  conceptual  design  to 
product  retirement  for  a  major,  emerging  military  large 
aircraft  system. 

(3)  To  construct,  build,  and  demonstrate  a  flexible  IDS 
prototype  system  that  can  be  rapidly  expanded  as  new 
technologies  emerge  in  the  areas  of  data  base  machines, 
advanced  design  and  analysis  graphics,  advanced 
communications,  and  artificial  intelligence. 

(4)  To  assure  that  the  system  design  reflects  capability 
for  upward  migration  and  portability. 
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(5)  To  develop  the  IDS  concept  in  a  production  environment 
that  will  provide  a  realistic  test  bed  for  requirements 
definition,  prototyping,  initial  build,  and 
demonstration. 

(6)  To  structure  the  IDS  design  so  as  to  facilitate 
transition  of  the  system  from  the  research  and 
development  and  prototype  stages  into  a  production 
system. 

(7)  To  demonstrate  and  prototype  IDS  in  a  manner  that  will 
provide  the  baseline  for  future  technical  information 
management  on  all  Air  Force  weapon  systems. 

(8)  To  formulate  draft  requirements  to  be  used  as  a 
baseline  for  establishing  technical  data  requirements 
for  future  Air  Force  systems. 

Rockwell  is  also  involved  with  the  Analytical  Sciences 
Corporation  of  Reading,  Massachusetts  in  the  initial  phase 
of  an  Air  Force  program  to  develop  and  implement  a  B-1B 
Logistics  Technical  Support  Center  (TSC).  This  program  will 
establish  a  management  and  technical  center  for  Air  Force 
logistic  support  for  the  B-1B  weapon  system.  The  center 
will  also  provide  operational/readiness  status  capability  to 
the  Air  Logistics  Center  (ALC)  B-1B  system  manager  and  will 
provide  technical  information  support  between  contractor, 
depot,  and  operational  repair  facilities. 

The  IDS  will  provide  advanced  data  base  management  and 
communications  concepts  in  support  of  the  TSC.  Advanced 
prototypes  of  the  IDS  (Advanced  Information  Management 
Concepts)  and  the  Technical  Support  Center  (advanced  control 
and  technical  communication  concepts)  are  scheduled  for 
fiscal  1986. 

The  attached  graphic  exhibits  presents  the  evolving  IDS 
concept  as  it  is  applied  to  a  major  weapon  system  --  the 
B-1B  Bomber. 


E.  SUMMARY 


The  United  States  Air  Force  is  stepping  beyond  traditional 
methods  of  data  base  management  in  the  IDS  program.  More 
powerful  microoomputers  and  data  base  machines,  new  data 
and  information  models,  and  the  effective  use  of  distributed 
data  in  a  heterogeneous  environment  are  all  part  of  this 
research  effort.  IDS  could  well  prove  to  be  the  data  base 
solution  that  everyone  is  looking  for.  If  so,  the  significance 
of  IDS  could  be  tremendous  resulting  in  replacement  of 
more  standard  data  structures  thereby  reducing  computer 
and  storage  costs  and  providing  networking  between  dissimilar 
computer  systems.  Every  government  agency,  as  well  as 
all  of  industry,  needs  this  capability.  The  IDS  program 
will  prove  workable  concepts  in  a  prototype  system  before 
transferring  these  developments  to  a  production  system. 


John  Willis 
Darrell  Cox 

Rockwell  International 
October  10,  1984 
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FIGURE  -  3 

SELECTED  MAINTENANCE  LOGISTICS  SUPPORT  DATA  SYSTEMS 
CONTRACTOR  AND  GOVERNMENT 

Rockwell  Management  and  Data  Systems 
LMDS  -  Logistics  Management  Data  System 
LSDS  -  Logistics  Support  Data  System 
PIOMS  -  Provisioned  Item  Order  Management  System 
SEMIS  -  Support  Equipment  Management  Information  System 
TOTS  -  Technical  Order  Tracking  System 
LIMS  -  Logistics  Inventory  Management  System 
ICSIS  -  Interim  Contract  Support  Information  System 
MCC-ICS  -  Management  Control  Center  Interim  Contract  Support 
MCS  Boeing  -  Management  Control  System 
CETS  -  Contract  Engineering  Technical  Support  System 
IDS  -  Integrated  Design  Support  System 

CITS  -  Central  Integrated  Test  System  Ground  Processing 
System 

EACN  -  Emergency  Airborne  Communications  Network 

U.S.  Air  Force  Management  and  Data  Systems 
CAMS  -  Core  Automated  Maintenance  System 
OMS  -  Logistics  Management  System 
LOC  -  Logistics  Operations  Center 

IMMS  -  Integrated  Maintenance  Management  System  comprising 
MICAP,  MDC,  AWP,  and  AVISURS 

CMS  -  Combat  Maintenance  System 

WSMIS  -  Weapon  System  Management  Information  System 
SAC  -  Strategic  Ai*  Command  Operational  Data 
MICAP  -  Mission  Capability  System 
MDC  -  Maintenance  Data  Collection 
AWP  -  Awaiting  Parts  System 

AVISURS  -  Aerospace  Vehicle  Inventory,  Status  and  Utility 
Reporting  System 
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IDS  SYSTEM  BUILD  (6.4) 


B-1B  DESIGN,  MANUFACTUIRNG,  AND  / 

LOGISTICS  DATA  BASES  /  B1B  OPERATION 


Figure  5  -  IDS  Development  Program  Relationships 
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FLOW  OF  INFORMATION  IN  DEFENSE  PROGRAMS  EMPLOYING 
STATE  OF  THE  ART  LOGISTIC  TECHNOLOGY  AND  A 
GENERAL  LOGISTIC  INFORMATION  MODEL 


October  19»  1984 


by 


Darrell  Cox,  Rockwell  International 
George  Beiser,  Institute  for  Defense  Analyses 


FLOW  OF  INFORMATION  IN  A  6ENERAL  LOGISTIC  INFORMATION  MODEL 


The  CALS  has,  as  its  root,  a  concept  that  is  broad  enough  to  encompass 
each  individual  logistic  function  across  the  entire  range  of  weapon  systems, 
addressing  each  system  from  its  definition  through  its  disposition.  It  must, 
accurately  and  in  real  time  (or  near  real  time)  process  data/information  sets 
from  their  various  sources,  in  their  respective  formats,  through  their  many 
transformations  and  transfer  media.  And,  most  importantly,  it  must  achieve 
this  objective  in  a  positive  program  environment.  CALS  is  a  truly  challenging 
idea. 

The  CALS  concept  virtually  requires  an  information  flow  model  to  show  the 
entities  and  the  dynamics  of  so  broad  and  so  potentially  powerful  an  idea. 

The  attached  Figure  1,  "General  Logistic  Information  Model,"  is  a  preliminary 
effort  toward  graphical  representation  of  the  total  CALS  concept.  The  draft 
Model  has  attempted  to  follow  MIL-STD-1388-1A  as  closely  as  possible.  The 
Model  consists  of  four  main  panels  that  can  indicate  the  activities  that  may 
be  required  for  the  automated  support  of  any  likely  logistic  objective  and  the 
steps  toward  its  achievement. 

For  the  sole  purpose  of  illustrating  the  scope  of  this  preliminary  Model, 
a  complete  but  relatively  small,  highly  adaptable,  weapon  system  is  assumed. 
The  chosen  weapon  system  is  a  multi-purpose  multi-service  helicopter.  This 
system  is  intended  to  be  a  composite,  generic  product  with  which  almost  any 
conceivable  logistic  problem,  analyses  and  solution  can  be  represented. 

In  its  present  draft  status,  only  the  first  panel  of  the  Model,  dealing 
with  the  weapon  system  Preconcept  and  Concept,  is  filled  in.  The  remaining 
panels  require  appropriate  functions  and  entities  that  are  suggested  by  the 
first  panel  representation. 
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The  activities  that  are  performed  by  a  wide  variety  of  operators  are 
listed,  in  Panel  1,  as  "a"  through  "ah."  These  operations  or  functions  are 
separated  into  three  groups--designers,  resource  controllers  and  logisticians-- 
with  an  indication  of  the  type(s)  of  data/information  that  likely  are  available, 
and  the  typical  computer-aided  technology  (CAT)  output  of  that  performer. 

This  chart,  in  spite  of  its  detail,  may  be  too  highly  aggregated  to  be 
useful  in  analyzing  a  specific  logistic  problem.  Therefore,  Figure  2, 

"Analyses  of  an  Individual  Logistic  Step"  is  provided.  This  permits  selecting 
a  small  step  and  (1)  considering  the  specific  type  of  information  available, 

(2)  its  format  and  method  of  data  entry,  and  (3)  the  specific  type  and  character¬ 
istics  of  the  computer-type  device  employed  to  achieve  a  stated  objective. 
Provision  also  is  made  for  indicating  the  output  information  format  and  method, 
and  the  specific  type  of  information  output  that  results. 

This  approach  is  intended  to  provide  both  a  general  and  a  specific  means 
of  walking  through  a  requirements  or  logistic  problem  and  identifying  graphically 
and,  at  least,  qualitatively,  the  CALS  procedures,  limitations  and  potential 
remedies.  A  series  of  Model  exercises,  involving  real  products  or  reasonable 
simulations,  is  likely  to  result  in  "clustering"  of  events  (problems,  gaps, 
solutions)  or  resources  (performers,  equipments)  that  would  help  make  CALS 
a  more  manageable  program.  Comments  and  suggestions  toward  this  end  are  invited. 
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Figure  la.  FLOW  OF  INFORMATION  IN  A  GENERAL  LOGISTICS  INFORMATION  MODEL 


Figure  lb.  FLOW  OF  INFORMATION  IN  A  GENERAL  LOGISTICS  INFORMATION  MODEL 
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Figure  2.  ANALYSIS  OF  AN  INDIVIDUAL  LOGISTIC  STEP 

(continued) 
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SCOPE  OF  CALS 


SUMMARY 

As  CAD  and  CAM  have  widely  computerized  the  design  and 
manufacturing  processes,  providing  extensive  data  bases, 
Computer  Aided  Logistics  Support  (CALS)  is  seen  as  the 
computerization  of  Integrated  Logistics  Support  processes. 
CALS  is  the  master  plan  affecting  the  activities  of  each  ILS 
element  organization,  their  interfaces  with  each  other,  with 
CAD/CAM,  with  government  departments,  and  with  contractors. 
Ultimately  it  will  be  implemented  across  all  weapon  systems 
and  all  four  services. 

Many  programs  exist  or  are  under  development  today  for 
automating  technical  information.  An  output  of  CALS  is  the 
coordination  of  these  programs  to  enhance  the  computer  aided 
operations.  In  order  to  implement  efficiently  this  multi¬ 
weapon  system,  multi-service  concept,  standards  are  needed 
to  define  common  terms  and  data  requirements  in  each  ILS 
element  area.  The  LSA/LSAR  is  the  mainstream  analysis 
process  upon  which  CALS  should  be  built.  Excellent  data 
requirement  standards  are  in  being  including  MIL-STD 
1388  -  1A  and  soon  to  be  released  -2A,  while  other  important 
interface  standards  are  in  formulation,  such  as  IGES, 

GENCODE  and  GKS . 

A  number  of  issues  need  to  be  considered  in  the  tech¬ 
nological  scope  of  CALS: 


Which  logistic  support  processes  are  likely  to  be 
computer  assisted  to  most  effectively  implement 
CALS? 
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How  many  and  what  types  of  data  bases  will  make 
up  CALS? 

Can  data  base  management  be  independent  of  imple¬ 
mentation  of  CALS? 

What  degree  of  data  base  transportability  should 
exist  in  CALS? 

What  standards  are  needed  in  data  base  structure 
and  what  languages  to  aid  transportability  of 
data  bases  within  CALS? 

What  logical  information  model  is  needed  for 
CALS? 

How  much  restructuring  of  existing  data  systems 
is  required  for  CALS  in  order  to  accommodate 
required  interfaces  between  systems? 

Will  CALS  be  implemented  in  phases  based  on  tech¬ 
nology  availability? 

What  media  will  be  used  to  transmit  CALS  information 


DISCUSSION 

Before  delving  into  the  "Scope  of  CALS,"  Computer 
Aided  Logistics  Support  needs  to  be  fundamentally  defined 
and  its  purpose  explained.  Computer  Aided  Logistics  Support 
is  the  computerization  of  Integrated  Logistics  Support 
processes,  just  as  Computer  Aided  Engineering  is  the  computer¬ 
ization  of  engineering  processes;  as  CAD  is  to  the  overall 
design  effort;  and  as  CAM  is  to  the  manufacturing  effort. 

The  purpose  of  CALS  is  to  increase  productivity,  increase 
readiness  and  support,  reduce  risk,  and  decrease  cost, 
while,  according  to  the  DoD,  providing  a  more  manageable 
data  base,  giving  the  government  better  access  to  the  weapon 
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system  data  base,  and  enhancing  the  post-production  phase 
spare-parts  provisioning  and  modification  efforts. 

One  of  the  major  goals  for  CALS  is  to  have  it  tied 
into  the  basic  data  bases  of  CAD  and  CAM.  A  function  of 
ILS  is  to  influence  the  initial  concept  of  a  weapon  system, 
and  hence  the  preliminary  design,  to  enhance  support. 

It  can  be  seen  in  the  preliminary  design  stage  that  the 
logistics  data  base  needs  to  be  linked  to  the  product  defini¬ 
tion  process,  thus  providing  the  input  basis  for  automating 
LSA,  simulations,  logistics  assessments,  etc.  Alternative 
design  approaches  to  the  support  concept  will  be  considered 
based  on  cost  effectiveness  tradeoffs.  Given  more  "real 
time"  availability  of  the  results  of  logistics  analyses 
conducted  concurrently  with  the  design  definition  that 
evolves  in  the  product  definition  data  base,  logisticians 
will  have  the  opportunity  to  truly  impact  the  design. 

These  thoughts  reflect  the  importance  in  "conceptually" 
reflecting  support  in  the  preliminary  design  phase. 

The  current  interface  between  CAD/CAM  and  tne  ILS 
data  base  is  mostly  manual  and  on  paper.  Some  interfaces 
are  already  computerized  and  there  are  growing  numbers 
of  DoD  programs  researching  the  computerization  of  various 
elements  of  other  interfaces.  Computerized  ILS  and  CALS 
is  seen  to  include  modeling,  accounting,  interdependency 
"trees,"  and  analyses  (particularly  LSA). 

Computer  Aided  Logistics  Support  should  apply  to  the 
full  depth  and  span  of  logistics  activities,  that  is,  to 
the  ten  ILS  element  functions  as  defined  in  DODD  5000.39. 
These  include:  Supply  Support;  Technical  Data;  Facilities; 
Manpower  and  Personnel;  Packaging,  Handling,  Storage  and 
Transportation;  Training  and  Training  Devices;  Support  , 
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and  Test  Equipment;  Computer  Resources  Support;  Maintenance 
Planning;  and  Design  Interface  activities  including  Reliability 
Maintainability  and  Human  Factors.  CALS  should  span  the 
entire  program  life  cycle  beginning  with  the  pre-concept 
phase  and  progressing  through  disposal. 

In  being  such  an  all  encompassing  activity,  CALS  should 
be  a  DoD  established  network  of  data  systems  that  establishes 
the  mechanisms  and  provides  the  standards  for  the  collection 
of  all  logistics  related  elements  applicable  to  all  weapon 
systems.  CALS  should  be  general  and  flexible  enough  to 
be  applicable  to  all  military  services’  and  government 
contractors’  logistics  requirements. 

The  mechanisms  for  supporting  CALS  should  include 
all  the  data  bases,  computers,  communication  linkages, 
recording  media,  software,  etc.  necessary  to  provide  compat- 
ability  among  the  participating  contractors  and  services. 

CALS  must  be  responsive  to  activities  performed  by  the 
producing  activities  including  the  System  Program  Office, 
the  Air  Logistics  Centers  and  the  Government  Laboratories. 

CALS  must  be  compatible  with  the  activities  including  opera¬ 
tional  units  and  the  associated  support  activities  at  all 
levels. 

Although  it  might  be  possible  to  have  a  centralized 
computer,  data  base,  etc.  to  support  CALS,  it  would  probably 
not  be  very  practical.  If  the  services/contractors  did 
not  necessarily  use  the  same  mechanisms  to  support  CALS, 
these  mechanisms  would  have  to  have  a  certain  amount  of 
standardization/compatability  to  permit  transportability 
of  the  various  data  elements  and  permit  communication  between 
the  participants.  This  leads  us  to  one  of  the  major  challenges 
namely,  developing  a  comprehensive  set  of  standard  data 


definitions  for  commonly  used  logistics  parameters.  One 
suggestion  is  to  build  upon  the  existing  Data  Item  Descriptions 
to  achieve  this  commonality  of  parameter  definitions. 

A  DoD  Directive  (similar  to  5000.39  perhaps)  should  require 
the  establishment  of  a  military  standard  (similar  perhaps 
in  intent  to  MIL-STD- 1 388-2A )  that  would  establish  data 
element  needs,  define  data  element  formats,  define  necessary 
interfaces  with  existing  systems  and  future  systems,  define 
applicability  to  various  weapon  systems  phases,  define 
system  coordinating  agencies,  etc. 

CALS  should  consist  of  information  data  bases  and 
expert  systems  (including  artificial  intelligence).  In 
developing  CALS,  the  following  technical  issues  should 
be  included: 

Application  of  embedded  computer  resources  (computers, 
software  and  firmware)  in  weapon  systems. 

Breakthroughs  in  microelectronics  make  possible 
smaller  and  faster  computers  that  will  expand 
the  use  of  embedded  computers  in  future 
weapon  systems.  Embedded  computers  will 
have  a  long  range  impact  on  both  the  operation 
and  logistics  support  of  weapon  systems. 

CALS  must  interface  with  and  support  these 
embedded  systems.  Techniques  for  influencing 
the  design  of  software  and  firmware  will 
be  different  from  that  of  conventional  hardware. 
Maintenance  and  support  of  embedded  computer 
resources  will  also'be  different  from  that 
of  hardware. 

Solid  state  technology  using  firmware  in  lieu 
of  software. 
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Teleprocessing  (combined  use  of  communications 
facilities  and  data  processing). 

With  computer  costs  dropping,  the  widespread 
use  of  microprocessors  is  making  the  transfer 
of  information  more  economical.  Teleprocessing 
is  also  aided  by  advances  in  VLSI,  digital 
techniques,  satellites  and  optical  fibers. 

Standardization  of  higher-order  languages  and 
architecture  of  interfacing  systems. 

There  are  many  programs  in  development  that  revolve 
around  automating  logistics  data  bases.  These  include 
the  Air  Force:  ATOS,  EDCARS ,  MIDAS,  IDS,  ICAM,  CIM,  IMIS, 
GIMADS,  and  LIMSS.  For  these  to  be  widely  used  by  multiple 
commands  and  contractors,  communication  networks  such  as 
DDN  and  LAN  must  be  fully  developed.  The  Army  and  Navy 
also  have  many  such  efforts.  For  these  programs  to  eventually 
evolve  into  CALS,  considerable  government  support  will 
be  essential  and  contractors  must  be  provided  substantial 
incentives  to  invest  in  the  added  automation. 

The  scope  of  CALS  must  be  broad  enough  to  encompass 
these  multiservice  programs  and  ensure  the  standardization 
of  their  basics  while  relaxing  on  the  "how  to,”  particularly 
when  affordability/low  costs  dictate.  To  achieve  this 
multiservice  system  approach,  cultural  and  ”rice  bowl” 
barriers  between  the  functional  specialty  groups  in  the 
DoD  acquisition  establishment  must  be  broken  down.  Industry 
will  then  follow. 

The  evolutionary  approach  will  see  the  coordination 
of  the  many  existing  programs  and  increasing  application 
of  the  pilot  programs.  These,  by  economic  necessity,  will 
be  incorporated  in  new  weapon  system  programs  and  gradually 


expanded  across  the  services.  Thus  a  long  term  program 
is  expected,  as  represented  in  Figure  1. 


Prepared  by  ILS  Department 
For  Fred  Macey 
Lockheed-Georgia  Company 
October  1984 
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Figure  1.  AUTOMATING  THE  GENERATION  OF  THE  PRODUCT  DEFINITION  DATA  BASE 
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Figure  2.  COMPUTER  AIDED  TECHNICAL  MANAGEMENT 
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COMPUTER  AIDED  LOGISTICS  SUPPORT  (CALS) 


COMPUTER  AIDED  LOGISTICS  SUPPORT 
MUST  BE  ORIENTATED  TOWARDS  THE 
DESIGNER’S  USE  AT  A  POINT  WHERE 
THE  CRUCIAL  AND  ROUTINE  DESIGN 
DECISIONS  ARE  MADE.  THE  CAD/CAM 
OFFERS  THIS  CAPABILITY. 


Advances  in  computerized  techniques  and  hardware, 
along  with  the  development  of  shared  and  on-line  data  base 
systems  have  made  design  for  supportability  a  reality. 

Research  in  defining  and  quantifying  supportability  has 
led  to  the  potential  ability  of  the  designer  to  interact 
with  the  supportability  engineer  in  a  user  friendly  environ¬ 
ment  in  sharing  each  other’s  knowledge.  This  shared  approach 
may  be  typified  by  a  computerized  workstation  that  permits 
development  of  top  level  and  detailed  Supportability  Design- 
to-Requirements  (SDTR’s),  and  translates  these  to  the  designers 
via  the  CAD/CAM.  Some  of  the  considerations  that  should 
be  addressed  are  given  below. 


PAYOFF 


The  Measures  of  Effectiveness  (MOE)  for  the  various 
weapon  systems  are  a  function  of  the  mission. 

Thus,  a  cargo  aircraft  would  be  different  than 
a  fighter,  and  as  a  corrollary  so  would  be  its 
respective  design  features.  In  general,  sortie 
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generation  capability  in  a  sustained  mode  under 
war  time  conditions  is  a  critical  MOE.  The  payoff 
is  then  the  ability  of  the  weapon  system  to  counter 
the  threat  with  a  reduced  force  size.  Because 
more  aircraft  are  available  for  combat,  the  payoff 
can  be  the  ratio  of  typically  required  aircraft 
versus  those  capable  of  the  increased  capability 
"to  fight  again." 

2.  The  immediate  introduction  of  supportability 

in  the  design  concept  formulation  phase  requires 
a  slightly  larger  investment  in  supportability 
engineering,  but  certainly  far  less  than  the 
offset  in  FSED  through  ECP  activity.  Another 
payoff  is  the  fact  that  a  smaller  supportability 
staff  is  needed  because  with  the  proper  tools 
more  efficient  use  is  made  of  information  during 
the  intense  proposal  activity  by  government  and 
contractor  alike. 


A  payoff  overview  is  provided  by  the  following  matrix: 


PAYOFF  OVERVIEW 


GOVERNMENT 


Reduction  in  Analysis 
S  in  Acquisition  Process 
S  Specifications 
KELSA  Efficiency 


INDUSTRY 

Supportability  in  Weapon 
Systems 

Lower  LCC 

S  in  Acquisition  Process 
S  Specifications 
KELSA  Efficiency 


NEAR  TERM 

FAR  TERM 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

3.  A  shared  methodology  between  government  and  contractor 
provides  numerous  benefits  such  as:  data  compata- 
bility,  increased  communications  and  almost  real 

time  analysis.  Using  an  existing  enhanced  LSA, 
the  additional  supportability  parameters  are 
analyzed  through  the  "Use  Study,  Task  201"  and 
"Comparative  Analysis,  Task  203.”  This  process 
not  only  determines  the  needed  supportability 
parameters  for  consideration  of  a  new  weapons 
system,  it  also  provides  feedback  during  the 
entire  engineering  process. 

4.  Payoff  to  DoD  would  be  to  make  S  as  important 

as  performance,  and  will  result  in  greatly  reduced 
O&S  cost  by  affordable  acquisition  cost,  since 
S  incorporation  is  by  competitive  bid  for  FSED 
instead  of  sole-source  ECP  activity. 

5.  Industry  would  be  in  a  better  position  for  true 
competition  and  finally  get  the  funding  up  front 
to  incorporate  S  in  design. 

B.  INCENTIVES 

The  use  of  incentives  will  provide  the  impetus  for 
a  more  intense  contractor  response  and  the  pattern  evolved 
from  the  successful  F/A-18  program  should  be  considered. 

The  inclusion  of  specific  SDTR’s  in  specification  language 
will  give  each  contractor  inherent  incentive,  since  specifica¬ 
tions  are  wi'iin  the  engineering  domain  and  objectively 
analyzed . 
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TASKS/PROBLEMS  TO  EXPAND  CAD  TO  INCLUDE  SUPPORTABILITY 
ANALYSIS 


1 .  Hardware  -  The  hardware  for  the  Computer  Aided 
Enhanced  Logistics  Support  Analysis  (KELSA)  uses 
the  IBM  3081  mainframe  and  IBM  3278  and  3279 
terminals.  It  is  possible  to  obtain  emulators 
for  the  IBM  terminals  which  would  interface  with 
the  mainframe.  Use  of  various  peripheral  models 
can  be  made  on  personal  computers  which  are  down¬ 
loaded  into  the  mainframe.  Word  processors  that 
are  compatible  with  the  mainframe  help  reduce 
tne  workload  with  regards  to  loading  data  bases 
with  text  and  numbers.  The  CAD/CAM  terminals 

in  use  today  that  are  running  the  CADAM  software 
would  be  most  compatible  with  the  KELSA  software. 

The  problems  of  expanding  KELSA  into  the  CAD/CAM 
environment  are  essentially  not  hardware  related 
but  are  mainly  of  the  software  type.  Interface 
devices  may  be  a  means  of  directly  interfacing 
the  KELSA  with  CAD/CAM,  and  this  is  currently 
being  investigated.  As  already  pointed  out  by 
the  IDA  panels,  the  issues  of  standardization 
and  communication  media  requirements  will  dominate 
this  area  of  growth.  A  workstation  approach 
permitting  the  designer  and  the  supportability 
engineer  would  enable  each  to  work  efficiently 
and  within  an  ideal  communication  environment 
when  linked  through  tailored  software. 

2.  Software  -  The  KELSA  is  written  in  PL1  and  uses 
peripheral  models  that  are  written  in  FORTRAN. 

The  challenge  confronting  the  linking  between 
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the  unique  CADAM  type  language  and  those  of  the 
KELSA  is  the  main  concern.  Particularly,  the 
designers  need  only  know  those  technicalities 
directly  affecting  the  design  process  --  design 
information  must  be  "transparent"  and  address 
all  levels  of  the  weapon  system  indenture  level. 

Data  Bases  -  The  primary  data  required  for  KELSA 
is  the  weapon  system  performance  through  systems 
such  as  the  Automated  Maintenance  System  (AMS) 
at  Dover  AFB,  Delaware;  the  Maintenance  and  Opera¬ 
tional  Data  Access  System  (MODAS)  from  WPAFB, 

Ohio;  the  Visibility  and  Management  of  Operations 
and  Support  Costs  (VAMOSC)  also  at  WPAFB,  Ohio; 
and  the  Naval  Aviation  Logistics  Data  Analysis 
System  (NALDA). 

Although  much  of  the  data  concerns  itself  with 
labor  and  management  reporting  there  are  specific 
data  elements  that  provide  design  relatable  informa¬ 
tion.  It  is  the  area  of  design  relatable  information 
that  must  be  addressed  in  the  formulation  of 
new  data  bases.  However,  this  writer's  opinion 
is  that  most  of  the  necessary  data  elements  — 
a  combination  of  detailed  operational  and  maintenance 
data  --  already  exist  at  DAFB.  The  problem  exists 
in  that  existing  models  use  data  elements  that 
are  derivations  of  the  collected  data  elements. 

This  derivation  process  leads  to  ambiguity,  assumption 
and  data  bias.  Continued  research  is  necessary 
to  close  the  gap  between  the  data  requirements 
of  the  logistician  and  the  designer. 
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M.  Parametric  Analysis  -  As  a  result  of  the  necessary 
design  parameter  orientation  of  future  data  bases, 
it  should  be  relatively  easy  to  assemble  and 
catalog  design  elements  that  can  be  used  in  modeling 
such  as  early  parametric  analyses.  The  need 
for  such  parametric  analysis  exists  in  the  conceptual 
phases  where  supportability  requirements  can 
drive  the  decision  between  an  aircraft  with  "podded 
versus  embedded  engines"  as  an  example. 

5.  Issue  -  DoD  should  encourage  industry  to  specify 

S  for  competitive  evaluation  by  use  of  specification 
language  as  a  new  output  of  the  LSA.  Tailored 
S  specification  language  would  eventually  be 
part  of  the  Statement  of  Need  (SON)  for  each 
type  of  acquisition. 

6.  Use  an  overall  S  plan  approach  that  will  achieve 
1st,  2nd  &  3rd  generation  of  CAD  from  the  broad 

base  of  SDTR's/specifications  with  KELSA  enhancements 
to  the  LSA  process. 

7.  This  first  generation  broad  base  capability  has 
been  demonstrated  to  be  an  acceptable  tool  for 
the  advanced  design  organizations  in  one  company 
to  use  on  CAD  to  achieve  the  2nd  generation  level. 

The  front-end  S  analysis  process  used  at  Lockheed 
provides  the  basis  for  artificial  intelligence 
since  it  is  built  on  use  of  logic  that  can  be 
developed  into  artificial  intelligence. 

ADDITIONAL  CONSIDERATIONS 

Selected  Candidate  Weapon  System 
"Intended  use" 
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Design  for  S  Baseline 
A/C  Characteristics/Features 
Data  Base  of  SDTR ' s  for  above 
CAD  Graphics 

Quantification  of  SDTR's 

Graphic  representation  of  tailored  SDTR  features 
Tailored  SDTR's  for  System  Specifications 

Technology 

Data  Bases  (UDB,  MODAS,  etc.) 

KELSA 

Design  for  S  Handbook  with  tutorial  screen  approach 
Development  of  logic  flows  for  S  on  CAD  that 
can  lead  to  artificial  intelligence. 

Erich  Hausner,  ( 8 1 8 )  847-7032 
Bob  McCall,  (818)  847-7032 
LOCKHEED  -  CALIFORNIA  COMPANY 
October  1984 


REPORT  NO.  5 


ISSUE: 

SUPPORT  OF  CONTRACTOR /DOD  DECISION  PROCESS 

via 

-  AUDIT  TRAIL 

-  MANAGEMENT  OF  CHANGE 


Throughout  the  acquisition  process,  decisions  are 
made  by  contractors  and  DoD  agencies  that:  establish  alterna¬ 
tive  courses  of  action,  select  the  optimal  alternative, 
establish  plans  for  accomplishment,  and  affect  details 
of  implementation. 

This  decisionary  activity  is  an  iterative  process 
from  the  preconceptual  stage  through  all  program  life  cycle 
phases.  Each  decision  is  the  result  of  some  form  of  formal 
or  informal  trade-off  analysis  based  upon  the  "best  information 
available"  at  the  time  the  decision  is  made.  Unfortunately 
(and  fortunately),  the  "best  information  available"  is 
an  information  set  from  some  data  base(s)  that  constantly 
changes.  Hopefully,  the  changes  are  improvements  in  quantity 
and  quality. 

Paradoxically,  however,  the  constantly  changing  data 
elements  can  work  both  for  and  against  the  decision  process. 
Working  for  the  decision  process  is  relatively  straightforward: 
improved  timeliness  of  more  quantity  and  better  quality 
of  information  results  in  higher  quality,  better-informed 
decisions,  all  else  being  equal.  Working  against  the  decision 
process  is  more  subtle.  For  example,  the  information  set 
upon  which  a  specific  decision  is  made  may  be  irrevocably 
altered  with  new  data,  thereby  rendering  the  decision  result 


virtually  impossible  to  reconstruct.  The  audit  trail  disappears 
—  which  may  or  may  not  be  important  for  future  decision 
making. 

Therefore,  this  technical  issue  involves  determining 
the  requirements  for  controlling  and  recording  results 
of  the  decision  processes  that  establish  content  and  use 
of  digitized  information  in. a  complex  and  dynamic  data 
base. 

Any  substantial  data  base,  centralized  or  distributed, 
should  be  thought  of  as  a  virtual  living  entity.  The  data 
base  for  an  active  program  or  equipment  will  be  continuously 
changing  and,  in  most  cases,  growing.  If,  as  envisioned, 
the  data  base  is  utilized  in  a  paperless  scenario,  the 
magnitudes  and  rates  of  change  and  growth  will  be  virtually 
invisible  to  the  user.  Indeed,  the  mere  fact  that  the 
information  in  the  data  base  is  changing  may  not  even  be 
evident  to  the  user  .  .  .  nor,  maybe,  should  it  be.  All 
the  user  is  interested  in  is  readily  obtaining  the  information 
he  needs  in  a  timely  manner,  whenever  he  needs  it,  and 
with  confidence  in  its  accuracy  and  completeness.  Therefore, 
when  user  A  uses  information  set  I  from  data  base  DB  at 
time  T1  to  make  decision  D1,  he  (and  any  other  user)  should 
have  the  ability  to  retrieve  the  identical  information 
set  1  at  times  T2  and  T3  even  though  data  base  DB  will 
have  changed  to  data  base  DB'  or  DB’’. 

The  central  questions  are:  1)  How  do  you  establish 
and  maintain  an  audit  trail  in  a  dynamically  changing  data 
base,  especially  where  the  change  is  invisible  to  the  user? 
and,  2)  How  do  you  effectively  and  efficiently  manage  the 
magnitude,  frequency,  scope,  content,  extent,  etc.,  of 
change? 
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A  simple  analogy  is  offered  to  better  understand  this 
issue.  Consider  a  single  engineering  drawing  of  a  widget. 

It  starts  out  as  a  "no  change”  vellum  from  which  drawing 
copies  are  made  and  from  which  'widget-NCs'  are  manufactured. 
Then  an  engineering  change  is  made  that  makes  the  widget 
more  reliable.  A  drawing  of  'widget-NC'  is  put  on  file, 
and  the  vellum  is  altered  to  reflect  "change  A,”  the  more 
reliable  'widget-A.'  'Widget-As'  are  then  manufactured. 

Then  changes  B,  C,  D,  etc.,  occur  and  their  corresponding 
widget  configurations  are  manufactured.  All  configurations 
of  widgets  are  in  active  use  and  require  servicing  and 
maintenance.  The  engineering  drawing  vellum  reflects  only 
the  latest  widget  configuration,  but  copies  of  all  prior 
widget  configurations  are  stored  in  an  engineering  data 
center.  This  procedure  constitutes  a  simple  form  of  manage¬ 
ment  of  data  base  (the  engineering  drawing)  change,  and 
establishes  and  maintains  an  auditable  trail  of  change 
history. 

While  the  nature  of  the  digital  data  base  is  quite 
different,  the  requirement  to  maintain  multiple  configurations 
of  a  device  and  to  manage  the  changing  data  base  does  not 
change.  However,  the  question  of  'How  much  is  enough  for 
a  proper  audit  trail?'  becomes  more  prominent.  When  does 
the  amount  of  additional  data  required  in  the  data  base 
exceed  its  benefits?  When  does  the  change  management  function 
become  too  burdensome? 

Consider  the  case  of  the  widget  drawing  in  a  digitized 
data  base.  The  engineering  drawing  in  its  "no  change” 
configuration  is  represented  by,  say,  X  Kbytes  of  information. 
If  "change  A,"  the  reliability  change,  affects  and  changes 
10/t  of  the  X  Kbytes,  will  the  audit  trail  require  1 . 1 X 
Kbytes  of  storage  (the  original  "no  change"  configuration 
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plus  only  the  10$  that  has  been  changed),  or  2. OX  Kbytes 
of  storage  (the  original  "no  change"  configuration  plus 
the  complete  "change  A"  configuration)?  If,  additionally, 
changes  B,  C,  and  D  each  also  affect  10$  of  the  ’drawing,' 
will  the  computer  storage  requirement  be  1.4641X*  Kbytes 
or  5. OX  Kbytes?  (Assumes  only  changes  but  no  additions. ) 

The  potential  impact  of  audit  trail  requirements  on  computer 
storage  capacity  is  enormous.  Even  for  this  simple  example 
of  four  changes,  each  affecting  only  10$  of  the  latest 
’drawing'  configuration,  the  maximum/minimum  storage  require¬ 
ment  ratio  is  approximately  3.4.  Projected  to  hundreds 
of  thousands  of  drawings  and  documents,  and  the  requirement 
for  multiple  configurations  of  each  drawing  and  document 
for  audit  trail  and  other  purposes,  the  mere  data  storage 
issue  is  mind-boggling.  And  when  data  additions  (not  merely 
changes)  are  considered,  the  issue  becomes  even  more  complex. 

The  problem  to  solve  in  the  'digital  world*  is  to 
manage  data  change  so  as  to  drive  and  keep  the  maximum/minimum 
data  storage  requirement  ratio  as  close  to  1.0  as  possible 
while  retaining  the  flexibility  to  satisfy  the  users’  needs. 

The  storage  of  widget  configurations  in  the  ’paper 
example’  corresponds  to  the  maximum  (5. OX  Kbytes)  condition 
in  the  ’digitized  example.’  Each  drawing  configuration 
paper  copy  reflects  both  changed  and  unchanged  information. 

In  the  'paper  world’  this  repetition  and  storage  of  unchanged 
information,  while  not  desirable,  may  be  the  only  practical 
method  of  maintaining  an  audit  trail.  Not  so  in  the  ’digital 
world .  ’ 
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However,  the  ’widget  example’  addresses  only  the  storage 
of  data  on  the  end  item,  i.e.,  the  results  of  decisions. 

Is  this  sufficient  to  produce  an  adequate  audit  trail, 
or  should  the  rationale  behind  the  changes  also  be  stored? 
Should  the  reasoning  used  to  formulate  a  decision  that 
results  in  change  to  an  end  item  (drawing,  document,  etc.) 
also  be  stored  in  the  data  base?  If  so,  how  much  rationale 
is  required?  What  constitutes  sufficiency  or  adequacy 
for  the  audit  trail? 

ACTION  RECOMMENDED:  (to  support  the  decision  process) 

1 .  DEFINE  REQUIREMENTS  FOR  A  DECISION  AUDIT  TRAIL. 

How  much  data  is  needed  to  support  the  decision 
process? 

Is  it  adequate  to  store  only  results  of  decisions, 
or  is  there  also  a  requirement  to  record  and 
store  the  rationale  or  reasoning  for  arriving 
at  the  decision  results? 

2.  DEFINE  REQUIREMENTS  FOR  MANAGEMENT  OF  CHANGE. 

Recognize  that,  even  with  current  and  projected 
storage  capacity  capabilities,  everything  cannot 
be  stored.  What  are  the  limits  for  supporting 
the  decision  process? 


G.L.  Foreman 
Hughes  Aircraft 
October  1984 
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REPORT  NO.  6 

LIMITS  ON  DOD  ACTION 


Limits  discussed  here  pertain  primarily  to  the  extent 
to  which  DoD  invokes  new  requirements  and  developments, 
as  opposed  to  adapting  existing  and  ongoing 
capabilities  for  the  construction  of  CALS.  The  areas 
discussed  are  summarized  as  follows: 

Standards  -  DoD  should  take  an  active  role  in  shaping, 
developing  and  validating  existing  international 
standards  to  be  sure  that  CALS  needs  are 
accommodated  and  that  CALS  is  structured  to  those 
standards . 

Implementation  -  Strict  contractor  compliance  to  CALS 

requirements  should  be  demanded  and  validated,  but 
contractors  must  be  allowed  to  implement  CALS 
consistent  with  corporate  information  structures. 
Similarly,  users  should  be  allowed  a  wide  range  of 
processing,  storage  and  display  choices  as  long  as 
compatibility  with  CALS  is  achieved.  DoD  may  wish 
to  sponsor  and  fund  CALS  hardware/software 
packages  and  offer  them  to  contractors  and  users 
in  order  to  limit  government  costs. 

Networking  -  CALS  should  comply  with  mandatory  use  of 
DDN  as  the  backbone  network  for  all  DoD  users. 
Considerable  investment  will  be  needed  to  expand 
capacity  and  extend  DDN  to  thousands  of  government 
and  contractor  vendor  locations.  The  use  of 
commercial  networks  linked  to  DDN  should  be 
considered,  consistent  with  security  needs. 
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Security  -  Transparency  in  authenticating  each  query, 

and  in  routing  between  supplier  and  user  is  key  to 
the  CALS  concept.  Rather  than  burden  each 
supplier  and  each  user  with  cumbersome  procedures 
and  lists  of  authorized  participants,  these 
functions  should  be  performed  by  several 
government-operated  CALS  "Control  Centers." 

Flexibility  -  Supplier  responsiveness  must  be  required 
on  a  flexible  scale.  On-line  data  storage  should 
afford  response  times  in  the  order  of  seconds,  or, 
for  large  data  requests,  overnight.  Archived 
data,  and  non-automated  data  such  as  microfilmed 
drawings,  should  afford  delivery  in  days  or  weeks. 


Proprietary  Information  -  Much  design  data  is 

consideied  proprietary.  Contractual  regulations 
exist  to  accommodate  this  situation,  and  changes 
are  being  considered  to  address  rapid  electronic 
technology  turnover  and  post  production 
support/diminishing  manufacturing  sources  issues. 
CALS  should  not  attempt  to  solve  these  questions 
but  should  accommodate  the  contractual 
regulations.  CALS  is  likely  to  influence 
negotiations  on  what  data  really  must  be  labelled 
proprietary . 


Detailed  discussion  of  these  areas  follows. 


Standards 

Numerous  standards  applicable  to  CALS  exist,  or  are 
being  developed  and  expanded.  This  includes  standards 
for  data  format  (IGES  et  al),  interface  protocols  (ISO 
7-level),  data  elements  (MIL-STD-1 388 ,  DoD-D-100  et 
al).  It  is  difficult  to  imagine  that  DoD  requires  any 
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data  via  CALS  that  is  significantly  different  or  unique 
from  the  needs  of  at  least  some  other  users  on  the 


international  scale.  Some  tailoring  may  be  necessary 
to  adapt  such  standards  to  CALS  purposes,  and  their 
development  paces  may  be  slower  than  CALS  requires. 

However,  it  would  be  foolhardy  (for  both  time  and  cost 
reasons)  for  DoD  to  undertake  development  of  any  new 
but  duplicative  standard,  and  then  expect  contractors 
to  comply  with  both  the  CALS-unique  standard  as  well  as 
the  comparable  standard  the  rest  of  the  world  demands. 

What  DoD  should  do  is  take  an  active  part  in  shaping, 
developing  and  validating  the  international  standards 
to  be  sure  that  CALS  needs  are  accommodated  and  that 
CALS  is  structured  to  those  standards.  Infusion  of  DoD 
and  industry  technical  expertise  and  funding  into  the 
work  of  selected  standards  committees  may  be  the 
catalyst  needed  to  accelerate  the  developments  and  to 
accomplish  validation  for  CALS  purposes.  Such 
involvement  should  have  the  equally  important  objective 
of  assuring  that  revisions  of  a  standard  are  compatible 
with  earlier  versions,  so  that  CALS  users  of  any 
generation  can  access  data  structured  to  contemporary 
as  well  as  older  generations. 

Implementation 

As  CALS  information  suppliers,  contractors  must  be 
allowed  to  implement  CALS  compliance  consistent  with 
corporate  information  structures.  Strict  compliance 
should  be  demanded  and  validated  for  (1)  delivery  of 
all  information  in  standard  format  and  content,  (2) 
when  and  where  requested,  and  (3)  with  archival 
permanence.  But  the  contractor  should  not  be  fettered 


with  detail  requirements  on  data  base  structure  and 
management,  computer  and  storage  hardware,  software 
language,  CAD/CAM  system,  and  so  on. 

This  seems  to  imply  that  each  contractor  will  have  to 
develop  translators  to  convert  his  unique 
implementation  to  CALS.  In  the  short  term,  that  is 
likely  to  be  true  but  is  not  inordinately  burdensome 
because  most  modern  corporate  information  structures 
possess  inherent  flexibility  and  at  least  partial 
compatibility  with  standards,  such  as  IGES  and  ISO 
interface  protocol.  A  market  will  evolve  for  software 
specialists  to  develop  such  translators  at  reasonable 
cost . 

In  the  longer  term,  it  is  very  likely  that  software 
specialists  will  market  general  purpose  or  tailored 
turnkey  packages  that  might  encompass  not  only  CALS 
requirements  but  also  major  portions  of  internal 
corporate  information  needs,  in  much  the  same  way  that 
MIL-STD-1388  has  spawned  numerous  and  progressively 
more  capable  LSA  software  packages.  DoD  may  wish  to 
sponsor  and  fund  such  a  package  and  offer  it  to 
contractors  in  order  to  limit  government  cost.  Each 
contractor  then  could  choose  to  use  it  in  toto  or  in 
part,  tailor  it,  or  develop  a  unique  package. 
Contractors  are  willing  to  share  with  DoD  reasonable 
investments  in  this  area  in  the  expectation  of  a  return 
based  on  increased  productivity,  and  to  limit  the 
intrusion  of  DoD  into  corporate  information  structures. 

CALS  users  should  be  expected  to  have  local  (if  not 
private)  data  processing  and  storage  capability. 

"Dumb"  terminals  should  not  be  serviced  directly  by 
CALS.  This  is  a  reasonable  constraint  because 
products , 


products,  such  as  personal  computers,  will  continue  to 
proliferate  as  cost  declines  and  capability  increases. 
Such  local  capability  will  be  sized  to  the  data  needs 
of  the  user  who  will  have  his  own  local  data  base. 

This  will  have  the  very  practical  effect  of  minimizing 
network  capacity,  and  reducing  user  dependence  on  a 
CALS  network  that  is  subject  to  pre-emption  for 
comraand/control  during  stress  or  to  disruption  by 
hostile  action. 

Because  of  wide  variation  in  user  needs  and  rapid 
advances  in  products,  CALS  should  not  mandate  a 
specific  user  workstation.  DoD  may  wish  to  sponsor  a 
family  of  commercial  or  military  workstation  devices 
and  software,  but  should  not  exclude  other  products 
that  can  be  made  compatible  to  CALS.  Special 
workstations,  such  as  portable  displays  for  flight  line 
and  field  maintainers,  should  be  compatible  with  CALS 
but  should  be  developed  for  specific  weapon  systems  or 
as  service-wide  projects  apart  from  CALS. 

Networking 

The  Defense  Data  Network  (DDN)  is  mandatory  for  all  DoD 
users  as  the  backbone  network  (secure  and  non-secure ) . * 
CALS  should  comply  with  this  policy,  but  considerable 
additional  funding  to  expand  transmission  capacity  and 
add  terminal  access  will  be  necessary.  Funding  is 
currently  provided  by  tri-service  shares  rather  than 
direct  charge  to  each  new  user.  Hardware  delivery  and 
installation  delays  are  likely  to  be  a  major  problem. 


OSD  policy  statement  10  March  1983 
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Contractors  are  connected  to  DDN  if  sponsored  by  a 
government  agency.  However,  no  clear  policy  has  yet 
been  established  for  interconnections  between  DDN  and 
commercial  networks.  CALS  may  be  unable  to  justify  the 
cost  of  extending  DDN  directly  to  thousands  of 
individual  contractor  and  government  locations.  Some 
strategy  is  necessary  to  allow  contractors  to  connect 
to  DDN  via  private  or  commercial  networks  or  other 
government  networks. 

This  would  ease  the  burden  on  DDN  expansion  by 
transferring  much  of  the  burden  to  commerical  networks 
which  have  shown,  and  can  be  expected  to  continue,  a 
willingness  to  respond  to  rapidly  increasing  demand  for 
services.  Initial  investment  is  recovered  in  time  via 
subscriber  usage  billings,  which  will  have  to  be 
considered  in  CALS  funding. 

However,  security  risk  from  "hackers"  or  more 
deliberate  intruders  gaining  access  to  DDN  must  be 
considered.  The  user-authentication  protocol  provided 
at  each  DDN  gateway  and  terminal  access  controller  must 
be  reviewed  for  adequacy  in  managing  the  added  security 
exposure.  In  addition,  adequate  encryption  of 
classified  CALS  data  for  transmission  over  commercial 
facilities  must  be  considered. 


Security 

Security  against  unauthorized  access  and  for  integrity 
of  the  data  base  is  a  growing  problem  for  information 
automation  in  general,  no  less  for  CALS.  Most 
strategies  depend  upon  the  information  supplier  to 


demand  from  each  user  adequate  identification  via 
suitably  complex  passwords,  together  with  physically 
secure  transmission  facilities  or  data  encryption. 

DDN  provides  military-grade  encryption  at  designated 
ports  for  classified  traffic  and  normally  routes  such 
traffic  over  dedicated  facilities.  Separate  facilities 
carry  unclassified  traffic  and  employ  the  commercial 
Data  Encryption  Standard  for  CONUS  traffic  and 
military-grade  encryption  overseas.  NSA  gateway 
devices  allow  classified  traffic  to  use  the 
unclassified  network  in  times  of  stress  or  emergency. 

DDN  appears  to  contain  inherent  security  measures  that 
are  adequate  for  CALS  communications  but,  like  most 
"public"  networks,  does  not  address  the  issue  of 
supplier-user  authentication,  which  is  traditionally 
left  to  each  subscriber  to  resolve.  Conventional 
measures  require  a  typical  data  base  owner  (i.e.  the 
prospective  CALS  supplier)  to  maintain  a  list  of 
authorized  users  with  appropriate  authentication  codes. 
Any  CALS  user  with  a-need-to-know  should  have  access. 
But  the  world-wide  list  of  such  users  for  a  major 
weapon  system  could  number  in  the  thousands  and  change 
daily.  Expecting  each  data  supplier  to  maintain  a 
current  list  and  enforce  confidentiality  of 
authentication  codes  poses  a  security  management 
nightmare . 

Conversely,  expecting  each  user  to  maintain  a  current 
file  of  data  suppliers  for  all  of  the  equipment  and 
parts  under  his  purview  for  use  in  addressing  and 
routing  a  transaction  is  unrealistic.  DLSC  presently 
maintains  such  a  file  that  could  be  adapted  to  CALS. 
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Transparency  between  the  user  and  the  ultimate  supplier 
is  the  key  to  the  CALS  concept.  Both  the  security  and 
the  routing  transparency  issues  suggest  a  "CALS  Control 
Center"  concept  through  which  all  queries  initially 
flow  for  authentication  and  proper  routing.  Several 
regional  Control  Centers  would  contain  a  current  matrix 
of  authorized  users  for  each  supplier,  and  would 
perform  necessary  authentication  and  routing 
procedures.  Actual  supplier-to-user  data  transfer  may 
bypass  the  Control  Center  once  these  procedures  had 
been  completed,  in  a  concept  analogous  to  a  telephone 
switching  system  wherein  complex  "intelligent" 
equipment  is  involved  only  briefly  in  interpreting  the 
call  parameters  and  setting  up  the  physical 
connections . 

Flexibility 

Supplier  responsiveness  must  be  required  on  a  flexible 
scale.  High  usage  and/or  critical  information  (such  as 
maintenance  procedures)  may  justify  query 
responsiveness  on  the  order  of  seconds,  but  the  cost  of 
on-line  storage,  processing  and  transmission  capacity 
must  be  considered. 

Most  current  data  will  be  accessed  infrequently  so  that 
overnight  retrieval  and  delivery  should  be  adequate. 
Archived  data  (such  as  reprocurement  packages  for  out- 
of-production  equipment)  is  rarely  accessed  so  that 
query  responsiveness  on  the  order  of  days  should  be 
adequate . 

Provision  should  also  be  made  to  place  requests  via 
CALS  for  non-automated  data  (such  as  hard  copy  drawings 
from  small  vendors  who  choose  not  to  participate  in 
CALS  automation.  This  can  also  be  applied  to  existing 
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data  which  does  not  justify  the  cost  of  automation,  as 
well  as  data  generated  during  the  transition  phase 
before  CALS  completion). 

In  any  case  CALS  should  inform  the  user  for  each  query 
the  expected  response  time  and  the  delivery  medium 
(e.g.  telecommunications,  floppy  disk,  mail).  Should  a 
specific  query  demand  shorter  response  time,  CALS 
should  be  capable  of  invoking  priority  procedures  (at  a 
suitable  increase  in  cost  to  the  user). 

Proprietary  Information 

The  CALS  data  base  should  contain  all  necessary  data  to 
define  the  end  product,  by  either  the  original 
manufacturer  or  a  second  source  at  any  time  in  the 
future.  Some  key  rationale  that  substantiate  the 
particular  design  solution  should  also  be  part  of  the 
data  base  to  permit  someone  other  than  the  original 
designer  to  make  changes  in  function  or  to  reduce  cost, 
or  to  adapt  for  newer  manufacturing  processes.* 

Much  of  this  design  data  may  be  considered  proprietary. 
This  is  nearly  always  true  of  new  or  highly  competitive 
manufacturing  processes,  especially  the  integrated 
circuit  community  with  its  VHSIC/VLSI  processes.  As 
long  as  a  vendor  continues  to  manufacture  an  item, 
contractual  regulations  have  been  in  use  for  many  years 
to  accommodate  these  situations.  However,  when  the 


^Design  rationale  should  be  part  of  design 
reports,  but  often  resides  in  obscure  engineering 
notebooks.  CALS  itself  should  not  mandate  the 
publication  of  such  data,  but  should  afford  means  to 
store  the  data  and  provide  pointers  to  relevant 
reports . 


vendor  ceases  production  and  support,  reprocurement  is 
much  more  uncertain  and  costly,  unless  the  government 
has  purchased  the  proprietary  data.  Even  then 
manufacturing  processes  may  be  unique  to  that  vendor, 
and  may  still  be  considered  proprietary  for  other  items 
of  his  product  line.  DoD  is  currently  focusing 
attention  on  strategies  to  cope  with  post-production 
support  and  the  related  diminishing  manufacturing 
sources  problem.  CALS  should  not  attempt  to  solve  this 
tough  problem,  but  should  be  capable  of  accommodating 
whatever  solutions  are  implemented. 


George  W.  Fredericks 

IBM  Federal  Systems  Division 

31  October  1984 
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REPORT  NO.  7 


POINTS  FOR  HIGHLIGHTING  IN  THE  CALS  REPORT 


Here  I  bring  to  your  attention  11  points  which  I 
think  should  be  highlighted  in  both  the  TECHNICAL 
ISSUES  and,  consequently,  in  the  CALS  Reports: 

1 .  GENERAL 

The  main  purpose  of  logistics  —  roughly  —  is  to 
fix  what  was  not  properly  designed,  manufactured  or 
maintained,  and  to  replenish  consumed  materiel.  The 
main  goal  of  the  CALS  Program  —  at  least  in  its 
initial  phase  —  is  to  give  a  fast  start  to  a  strong 
supporting  computerized  environment,  which  would  stimu¬ 
late  automation  initiatives  within  functional  codes, 
and  also  to  provide  special  purpose  tools  to  functional 
codes  (i.e.,  turnkey  logistics  workstations,  or  logis¬ 
tics  application  software  packages)  which  will  improve 
performance  of  logisticians.  This  as  a  payoff  will 
help  to  resolve  technical  problems  of  lagging  produc¬ 
tivity  in  Defense  logistic  systems,  and  subsequently 
will  help  to  improve  DoD's  industrial  base. 

Three  major  factors,  as  I  see  it,  are  playing  a 
role  here:  unification,  data  management,  and  networks. 

In  attacking  the  CALS  issues  and  approaching  the 
execution  planning  we  have  to  consider  the  following 
experience  gained  in  development  of  ather  large  sys¬ 
tems. 

o  Overcollecting  data,  including  multi¬ 
ple  reentry  of  data; 
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o  Overdesigning  products  in  attempt  to 
cope  with  unknown; 

o  Underestimating  support  (variety  and 
cost) ; 

o  Underestimating  psychological  bar¬ 
riers  (i.e.,  drawing  authentication); 

o  Overcontrolling  systems  by  the  tradi¬ 
tional  hierarchy  of  organizations  due 
to  a  limited  human  capacity; 

o  Underestimating  continuous  drifting 
apart  of  products  in  service  and 
enabling  technologies; 

o  Attempting  to  solve  somebody's 
problems  in  lieu  of  ones  own. 

It  can  be  concluded  from  this  list  that  there  is  a 
need  to  analyze  department  by  department,  workfunction 
by  workfunction  ("walk  through")  regarding  how  much  and 
what  kind  of  technology  is  involved  and  will  improve 
the  performance  of  a  product  and  the  performance  of 
product  supporting  operations.  Information  engineering 
is  to  be  applied  after  that.  Documentation  of  this 
kind  should  be  the  No.  1  priority  in  CALS  group's 
planning. 

2.  BASIC  ISSUES 

Scope  of  basic  issues  remains  the  same;  techni¬ 
cal,  managerial,  financial,  and  legal.  All  technical 
issues  in  general  are  caused  by  a  conflict  between  the 
knowledge  needed  to  provide  material  required  by  con¬ 
temporary  defense  systems  and  ancient  techniques  of 
providing  such  material.  Accumulated  expertise  in  data 
communication  and  data  processing  technology  now  allows 
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incorporating  advanced  computer-aided  techniques  into 
conventional  logistic  execution  methods,  developing  new 
methods  and  extrapolating  these  new  methods  into  the 
future  defense  logistic  procedures.  In  addition  to 
technical  issues  which  were  discussed  and  published 
during  four  CALS  sessions,  and  with  reference  to  the 
above  there  is  a  need  to  emphasize  the  following: 

o  Data  communication  issue.  It  seems 
important  to  partition  the  communica¬ 
tion  issue  into  three  separate  cate¬ 
gories:  (1)  communication  supported 

by  a  single  uP  in  a  relatively  small 
organization;  (2)  communication  sup¬ 
ported  by  a  number  of  microcomputers 
in  a  relatively  large  organization; 

(3)  communication  among  variety  of 
organizations.  Each  of  these  three 
categories  would  have  its  own  quite 
different  issues  to  address,  but  in  a 
hierarchical  order. 

o  Geometry  vs.  text  issue.  A  critical 
problem  in  communication  is  the  lack 
of  understanding  of  the  meaning  of  a 
drawing.  A  drawing  is  required  to 
assure  compatibility  of  three  ingred¬ 
ients:  Customer  system,  Vendor  sys¬ 
tem,  and  Manufacturing  system. 

Digital  representation  of  a  drawing 
allows  rapid  extraction  of  informa¬ 
tion  for  plotting/drafting  a  part, 
for  engineering  analysis  of  this 
part,  and  for  manufacturing  this 
part.  There  are  numerous  software 
packages  which  intend  to  do  that.  At 
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the  same  time  there  are  no  programs 
that  would  extract  a  part  from  an 
assembly  drawing  if  only  the  part 
number  is  given,  or  answer  a  query 
without  human  intervention,  or  recog¬ 
nize  a  part  or  its  features  on  the 
basis  of  jargon  definition.  These 
capabilities  are  the  most  needed  in 
logistic  support.  So  the  text  and 
geometry  integration  is  a  very  impor¬ 
tant  initiative  which  will  help  to 
overcome  the  communication  barriers. 

o  Expert  systems.  Enabling  technolo¬ 
gies  and  products  in  service  are 
drifting  apart  during  the  lifecycle 
of  a  product.  It  is  obvious  in  the 
electronics  supply  and  in  Naval  ship 
maintenance  activities.  Expert  sys¬ 
tems  are  envisioned  as  playing  a  sub¬ 
stantial  role  in  the  process  of 
adding,  recovering  or  replacing  human 
expertise  in  parts  restoration  and 
other  repair  needs. 

o  Process  models.  Documentation  models 
need  to  be  incorporated  into  a  logis¬ 
tic  process  model.  Virtual  processor 
concepts  can  be  used  in  developing 
the  acquisition  process  models. 

o  Economic  justification.  ROI  is  dif¬ 
ficult  to  justify.  Conceptually  new 
methods  of  justification  are  to  be 
provided. 
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3.  STANDARDS 

Standards  in  their  unique  role  as  DoD  standards 
imply  "the  best  out  of  many,"  not  just  an  overregulated 
"only."  They  are  some  of  the  solutions  to  the  CALS 
task,  not  a  CALS  supposition.  They  will  derive  as  a 
result  of  CALS  strategy,  of  its  implementation  policy. 
On  the  other  hand  they  are  not  yet  standards!  They  are 
proclaimed  as  standards,  they  are  written  in  a  form  of 
standards,  because  we  want  them  to  become  standards. 
But,  what  they  actually  are  —  they  are  proposals  for 
unification  of  protocols,  formats,  etc.  They  will  be¬ 
come  standards  after  a  majority  (say,  60$  or  more)  of 
CALS/CAD/CAM/CAP  community  would  conform  to  them  and 
use  them  in  an  orderly  manner.  The  action  of  standard¬ 
ization  should  be  executed  cautiously:  extensive 
military  control  resulted  in  a  reluctance  of  90$  of 
commercial  business  to  get  involved  in  military  produc¬ 
tion. 

o  GENCODE  &  IGES,  Graphics  specifica¬ 
tions.  The  following  diagram  illus¬ 
trates  the  relationship  between 
applicable  graphics  hardware/software 
specifications.  The  unification 
around  graphics  and  text  can  have  a 
clout  in  standardization  effort,  but 
the  need  for  unified  techniques  in 
dozens  and  dozens  of  other  related 
processes  should  not  be  overlooked: 
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WEAPON  DB 


IGES  level 

APPLICATION  PROGRAM 

GKS,  PHIGS  level 

GRAPHIC  UTILITY  SYSTEM 

VDI,  VDM  level 

DEVICE  DRIVERS 

NAPLPS  level 


VIDEO  DEVICES 

The  text  markup  unification  is  essential,  no  doubt,  for 
training  and  assembly  manuals,  but  the  most  important 
and  effective  suggestion  would  be  to  expand  GENCODE, 
the  text  markup  specification,  into  drawing 
areas  —  for  Bill  of  Materials  (BoM)  markup.  BoM 
standards  are  needed  independently,  though. 

o  MIL-STD-100C  et  al.  via  its  drawings 
of  a  product  "hardware”  determines 
communication  quality  among  three 
communities:  users,  vendors  and 
producers.  This  mylar-based  product 
definition  unification  needs  addi¬ 
tional  regulation  in  time  of  transi¬ 
tion  to  knowledge  based  systems. 

Support  for  modification  of  DOD-STD- 
100C  is  needed. 
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o  Transition  period.  Transition  period 
requires  an  understanding  and  support 
of  all  three  communities.  Transition 
period  in  every  technological  change 
causes  uncomfortable  feeling  of 
jncertainty.  Duplication  (i.e.,  two 
carriers  —  mylar  and  magnetic  tape) 
or  redundancy  —  is  an  unavoidable 
price  for  reliability,  choice  of 
solutions,  ease  of  transition,  etc. 
Thorough  training  of  personnel  in 
combination  with  expert  software  sys¬ 
tems  might  serve  here  very  well. 

4.  DATA  BASE 

We  have  to  emphasize  continuously  that  data  bases 
themselves  are  unable  to  bring  order  into  the  real-life 
data  chaos.  It  is  good  to  show  that  data  is  primary, 
and  that  a  data  base  is  secondary.  Data  type,  data 
structure,  data  flow,  data  management,  data  transfer, 
data  reliability,  destruction/aging  and  data  refresh, 
etc.  —  have  to  be  studied  and  understood  before  any¬ 
thing  else  is  proposed  for  execution.  An  efficient 
data  management  system  cannot  be  a  stand-alone,  it  is 
to  be  supported  by  widely  dispersed  CAD/CAM  data  auto¬ 
mation  and  office  automation  systems  of  first,  second 
and  even  third  tiers.  When  in  a  critical  path  or  in  a 
scheme  or  sequential  (presumably,  automated)  processes 
of  acquisition  and  a  single  process  is  slow  (say, 
manual)  —  then  the  entire  acquisition  will  be 
dependent  on  this  manual  process,  and  efficiency  will 
be  dragged  down  by  the  inefficiency  of  this  manual  pro¬ 
cess.  A  data  base  is,  roughly,  a  filing  system,  there¬ 
fore,  it  should  be  addressed  by  the  Systems 
Architecture  Subgroup.  DBMSs  are  designed  to  operate 


these  files,  therefore,  they  should  be  addressed  by  the 
Information  Requirements  Subgroup.  There  are  no 
graphics  fields  in  the  PC's  data  bases,  so  when  a  data 
base  for  a  logistics  workstation  will  be  specified  it 
should  include  graphics  fields. 

5.  NETWORKS 

Conventional  networks  in  their  telephone  and  tele¬ 
communication  versions  were  designed  for  interactive 
short  messages  communication.  The  two  following  char¬ 
acteristics  of  DDN  should  be  considered  when  CALS 
network  is  proposed:  DDN  will  take  file  transfer  in 
packs;  DDN  won't  support  CAD/CAM's  3D  solids  represen¬ 
tation  in  interactive  mode.  I/O  devices  are  projected 
to  be  a  limiting  factor. 

6.  TURNKEY  CAL  WORKSTATIONS  (WS) 

Workstations  will  play  an  increasing  role  as  the 
CAD  WS  played  in  design.  It  might  need  a  large  variety 
of  functions  because  of  high  diversity  of  logistic  dis¬ 
ciplines.  Its  utilization  has  to  be  programmed 
accordingly.  Notice  that  out  of  12,000  companies  using 
computer  graphics  for  CAD  and  engineering  about  80$  are 
using  only  drafting  with  little  or  no  design. 

7.  FEEDBACK 

There  are  many  examples  of  systems  that  failed 
because  they  provided  a  forward  control  only.  Provis¬ 
ions  for  the  formal  feedback  (programmed,  structured, 
continuously  fed,  and  analogous  sensory),  along  with 
the  informal  (unstructured,  spontaneous,  sporadic) 
feedback  need  to  be  included  in  CALS  Report. 


8.  ACCESS  CONTROL 

This  topic  should  be  given  a  deeper  meaning  ^an 
just  an  access  control.  It  should  be  interpreted  as  a 
part  of  access  management.  This  access  management  is 
to  be  treated  as  a  separate  CALS  concept.  It  is 
required  to  stimulate  access,  stimulate  exchange  and 
creation  of  information,  not  just  to  prevent  undesired 
access.  Thorough  personnel  training  is  to  be  devised. 

9.  CALS  PILOT  PROGRAM  AND  DEMONSTRATION. 

Principles  and  ground  rules:  (1)  multiple  team 

approach  (example:  ITA  project  administered  by  DARPA) 
which  provides  an  expertise  and  a  base  for  discussion 
and  solution  selection;  (2)  it  cannot  be  a  stand-alone 
(as  a  reef  of  automation),  it  is  heavily  dependent  on 
interaction  and  support  from  a  large  network  of  subcon¬ 
tractors,  vendors  and  concerned  agencies;  (3)  its 
building  elements  should  not  be  unique,  only  specific 
logistic  procedures  can  be  unique;  (4)  an  industrial 
experience  has  to  be  considered:  KANBAN,  the  just-in- 
time  inventory  control  system  (Jap.);  Kawasaki  (Toshiba 
Tungaloy  plant);  Nijigata;  Messershraidt ;  Rolls-Royce; 
GE's  Motor  frame  manufacturing;  TI's  business  and 
CAD/CAM  logistic  support  system;  ICAM  (an  AF  program); 
IPAD  (an  AF  and  Navy  program),  etc.;  (5)  it  must  start 
from  emulation  on  a  model;  (6)  it  must  be  correlated  in 

the  length  of  time  with  the  stochastic  property  of 

0 

failures  and  life  cycle  of  a  selected  product;  (6)  the 
best  result  of  experimenting  and  demonstrating  on  large 
systems  can  be  obtained  if  to  start  It  from  a 
headquarters,  because:  (a)  HQ  has  less  boundaries,  and 
(b)  proliferation  of  the  developed  methods  downward 
should  go  smoother  and  more  natural. 


10.  INTEROPERABILITY 

It  depends  on  and  includes  transparency  of 
operating  systems,  application  software,  product  data 
definitions,  data  files  —  to  users  (organizations  and 
operators),  hardware  (uP,  I/O,  and  network).  This  is 
the  prime  arena  where  the  system  of  standards  is  a 
must( ! ) . 

1 1 .  ASSUMPTIONS 

When  assumptions  are  made  the  realism  is 
sacrificed.  Therefore,  a  minimum  number  of  assumptions 
explicitly  formulated  and  agreed  upon  is  a  must  for 
this  project.  They  may  include  such  hypotheses  ass 

o  Logistic  organizations  are  flexible 
enough  to  adopt  structural  and  func¬ 
tional  changes  imposed  on  the  organi¬ 
zations  by  an  aggressive  computeri¬ 
zation  program. 

o  CALS  represents  a  completely  new 
environment  where  we  cannot  learn 
from  the  past  and  are  pioneering. 

o  The  errors  along  the  way  won't  be 
serious . 

o  The  DP  community  understands  what  is 
required  of  data  bases  by  the  CALS. 

o  DLA  is  aware  of  the  many  redundant 
data  subsets  that  had  come  into 
existance  over  the  years. 

o  No  loss  of  data  is  assured. 
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In  conclusion  I  would  like  to  express  ray  satisfac¬ 
tion  with  the  creative  atmosphere  and  excellent  results 
generated  by  the  Technical  Issues  Subgroup. 


Dr.  Ernest  Glauberson 
PMS  309-41,  692-4050 
.October  15,  1984 
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CALS  DEMONSTRATIONS:  PROCESS 
AND  RECOMMENDED  AREAS 

As  a  result  of  changing  computer  technologies,  both 
hardward  and  software,  data  processing,  in  general,  and 
its  influence  on  logistic  activities,  it  is  important  that 
a  computer  aided  logistics  support  (CALS)  pilot  (demonstration) 
program  be  undertaken  immediately  to  resolve  the  many  technical 
issues  that  currently  face  the  Department  of  Defense  (DoD) 
and  will  be  facing  DoD  over  the  next  five  (5)  to  ten  (10) 
years  as  we  undertake  the  modernizing  of  our  forces  and 
the  automation  of  DoD  services. 

The  pilot  program  will  take  on  the  following  character¬ 
istics: 


Paralleling  of  functions  (that  is,  at  least  two 
(2)  contractors  addressing  the  same  technical 
issue  at  the  same  time.  This  process  will  provide 
DoD  with  comprehensive  responses/viewpoints  and 
varying  opinions  which  will  assist  reviewers 
in  making  the  best  technical  decisions). 

Contractors  will  utilize  a  sub-component( s)  or 
a  weapon  system  as  test  vehicles. 


From  this  pilot  program  will  come  the  technical 
direction  for  the  future  computer  aided  logistics 
support  for  all  services. 


Primary  emphasis  will  be  placed  on: 

Standards 

GENCODE  (SGML/DIF) 

IGES 

GKS 

Others  (1388,  ISO,  etc.) 

Data  Base  Management  Systems 

Overall  Data  and  System  Management 

Data  Storage  and  Access  Retrieval 

Network (ing)  Systems 

Defense  Data  Network  (DDN) 

Local  Area  Network  Systems  (LANS) 

Wide  Area  Networking 

Data  Security 

In  addition,  the  CALS  pilot  program  should: 

1.  Clearly  define  and  specify  the  ILS  master  data 
base. 

2.  Recommend  candidates  for  automation  and  candidates 
for  non-automating. 

3.  Provide  key  insight  into  data  transportability 
and  transferability. 
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This  pilot  program  should  be  performed  in  three  (3) 
phases: 

Phase  I.  Phase  I  represents  a  period  of  gathering  and 

proving  of  technical  facts,  at  the  unit  level, 
the  testing  of  concepts  and  philosophies, 
indepth  research,  formulation  of  guidelines 
and  standards,  and  live  test  demonstrations 
of  accepted  and  proven  advanced  technologies; 
demonstrating  applicability  to  logistics. 

Phase  II.  Phase  II  represents  the  subsystem  level,  where 
several  logistic  activities,  demonstrated 
at  the  unit  level,  are  integrated  to  perform 
a  large  number  of  logistic  operations.  Interfaces 
are  clearly  designed  and  tested,  compatability 
issues  are  resolved,  and  human  factor  issues 
are  worked.  This  phase  is  an  ordered  approach 
to  the  development  of  the  final  system  or 
system  level. 

Phase  III.  Phase  III  represents  the  system  level.  This 
is  the  phase  that  requires  all  the  units  and 
subsystems  operations  to  be  tested  and  demonstrated 
as  a  total  Computer  Aided  Logistics  System. 

This  approach  provides  visibility  to  DoD  in  ensuring 
that  the  CALS  system  provides  and  fosters  high  productivity, 
innovative  and  creative  approaches  as  well  as  solutions 
with  excellent  quality  products. 


Attachments  A  through  E  present  some  of  the  key  technical 
areas/issues  that  must  be  given  attention  as  we  proceed 

•j* 

with  the  CALS  demonstration s) . 

Attachment  F  illustrates  the  three  (3)  phases  required 
to  perform  a  thorough  pilot  (demonstration)  program.  + 


tAttachments  A-4  are  not  supplied  with  this  draft  of  Volume  V 


REPORT  NO.  9 


THE  COMPUTER  AIDED  LOGISTICS  SUPPORT  (CALS)  STUDY + 

PROLOGUE 

The  following  brief  description  cf  the  manner  in 
which  it  is  presently  proposed  that  IGES  and  GenCode* 
be  used  in  tandem  to  meet,  compatibly  and  concurrently, 
the  needs  for  Logistics  Documentation,  Technical  Data, 
and  Technical  Documentation  was  first  presented  to  The 
Technology  Issues  Subgroup,  Mr.  Darrell  Cox,  Rockwell, 
Chairman,  on  9  August  1984,  for  initial  consideration 
as  a  potential  recommendation  to  the  full  body,  The  Ad 
Hoc  Group  on  Computer-Aided  Logistics  Support,  being 
conducted  by  The  Institute  for  Defense  Analyses  under 
the  Sponsorship  of  Mr.  Russell  Shorey,  Director,  Weapon 
Support,  Office  of  the  Assistant  Secretary  of  Defense 
for  Manpower,  Installations,  and  Logistics. 

The  material  was  subsequently  presented  to  the 
attendees  of  TechDoc*  VIII,  GCA’s  Annual  Conference 
and  Workshop  on  Integrated  Text,  Graphics,  and  Stored 
Data  Publishing,  in  Denver  on  23  August  1984  to  provide 
an  awareness  of  the  IDA  Study  and  to  invite  the 
comments  of  those  in  attendance  from  the  Logistics  and 
Technical  Documentation  Communities. 

It  is  planned  that  an  expanded,  more-detailed 
version  of  the  approach  —  reflecting  the  joint 
considerations  of  the  National  Bureau  of  Standards, 
Automated  Production  Technology  Division,  Dr.  Robert 
J.  Hocken,  Chief,  for  IGES  and  general  standardization 
issues,  and  the  Graphic  Communications  Association  for 
GenCode*  and  other  dimensions  —  will  be  submitted  as 
the  Study  progresses. 

+This  document  is  an  edited  and  amplified  version  of  a 
paper  presented  to  TechDoc  VIII  at  Denver  Colorado  on 
23  August  1984  by  William  Tunnicliffe  of  Graphic 
Communications  Association. 
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The  purpose  of  this  presentation  is  to  acquaint 
you  with  a  study  that  is  underway  under  the  joint 
sponsorship  of  the  Office  of  the  Assistant  Secretary  of 
Defense  for  Manpower,  Installations,  and  Logistics  and 
the  Under  Secretary  of  Defense  for  Research  and 
Engineering.  CALS  stands  for  Computer-Aided  Logistics 
Support.  IDA  stands  for  The  Institute  for  Defense 
Analyses,  which  is  under  contract  to  perform  this  study 
and  to  come  up  with  some  recommendations. 

Figure  1  illustrates  the  fact  that  the  basic 
thrust  of  this  study,  coincidentally  enough,  has  to  do 
with  some  of  the  topics  that  we  have  been  addressing 
during  the  course  of  this  meeting.  The  general 
objective  is  to  combine  the  use  of  data  that  is 
prepared  and  entered  for  technical-data,  technical- 
documentation,  and  logistics-documentation  purposes. 

It  involves  exploitation  of  both  GenCode*  for  handling 
text  and  control  and  IGES  to  handle  the  output  and  data 
extracted  from  the  CAD/CAM  system  chain.  IGES 
considerations,  in  turn,  will  lead  into  considerations 
of  GKS,  VDM,  and  VDI. 

Figure  1  also  illustrates  the  recommendation  for  a 
multi-part  Handbook  consolidating  (by  direct  inclusion 
and/or  by  reference  and  total-unit  inclusion)  the  total 
set  of  standards  involved,  together  with  procedures  and 
background  information  describing  what  the  process  flow 
paths  are,  how  the  standards  interrelate,  and  what  the 
interface  requirements  are. 

You  may  look  at  Figure  2  as  a  conceptual  diagram, 
and  the  basic  points  to  which  I  would  like  to  invite 
your  attention  include  the  fact  that  the  CAD/CAM  chain 
which  goes  through  the  IGES  data  file  is  what  I  refer 
to  as  the  "main  line."  This  main  line  is  the 
manufacturing  path  through  which  you're  going  to  make 
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the  pieces  that  make  the  airplane,  and  make  the  pieces 
that  make  the  electronic  subsystem.  It  is  NOT 
basically  intended  for  TechData  or  TechPubs  purposes 
per  se.  Its  principal  thrust  is  to  enable  any 
conforming  supplier  to  take  an  IGES  data  file  and  to 
produce  that  same  piece  of  hardware  to  use  in  a  system. 
We  are  symbolizing  the  consolidation  of  all  data  in 
this  diagram,  taking  from  the  IGES  data  file  what  can 
be  taken  and  exploited  in  the  sense  of  illustrations, 
taking  what  can  be  introduced  as  text  for  TechDoc* 
purposes  through  a  GenCode*  or  SGML  approach,  and 
putting  this  into  one  consolidated  data  file  from  which 
you  may  extract  for  either  purpose  —  Logistics 
Documentation,  Technical  Data,  OR  Technical 
Documentation. 

The  general  approach  of  Figure  2,  with  respect  to 
the  IGES  Data  File,  is  to  afford  separate  consideration 
to  the  graphic  content  and  to  the  incorporated  data 
content.  Pure  drawing  content  goes  through  the 
Illustration  Extraction  Process  exclusively.  Drawing 
identifications  —  number,  title,  project  nomenclature, 
etc.  —  are  drawn  across  to  the  GenCode*  Files  for  data 
utilization  and  associated  control  information. 
Similarly,  Text  Annotations  go  through  the  Illustration 
Extraction  Process  if  needed  within  the  drawing  itself. 
Annotations  may  go  across  to  the  GenCode*  File  for 
conversion  to  typographic-form  annotations  —  as 
contrasted  to  its  native  "CalComp"  drawing  form  —  if 
so  desired.  The  Manufacturing  Data  would  go  to  the 
GenCode*  File  in  all  cases. 

Figure  3  symbolizes  the  manner  in  which  what  I 
refer  to  as  "illustration  extraction"  is  being 
investigated.  It  is  assumed  that  you’ve  heard  enough 
about  GenCode*  and  SGML  so  that  you  understand  how  the 
text  is  handled  and  the  purpose  here  is  to  outline  the 


avenue  of  investigation  for  the  art,  taking  it  in 
symbolic  form  from  the  IGES  Data  File  through  the 
interface  processor  into  an  Illustration  Workstation 
(to  which  reference  has  made  in  the  course  of  the 
meeting  so  far).  Within  the  Illustration  Workstation 
you  will  modify  the  drawing  to  the  extent  that  you 
can  —  selecting  out  the  desired  portions,  discarding 
the  portions  not  wanted,  and  giving  the  proper 
illustrative  emphasis  to  those  portions  selected.  This 
will  result  in  the  ability  to  store  less  data  in  the 
IGES  Symbolic  Archive  which,  in  essence,  feeds  the 
consolidated  data  base.  In  those  instances  where  you 
cannot  do  the  job  that  you  want,  you  then  may  consider 
using  a  GKS-oriented  Artist's  Terminal  to  create  new 
illustrations  or  to  perform  modifications  that  are  not 
possible  within  the  IGES  system.  These  new 
illustrations  and/or  modifications  can  then  go  into  a 
GKS  Symbolic  Archive  —  IF  you  can  not  get  them  back 
into  the  IGES  terminology  and  store  them  in  the  IGES 
Symbolic  Archive. 

External  art  (supplied  art  or  art  created  outside 
of  the  system  shown)  can  be  of  line  form  or  tonal  form. 
These  are  fed  through  the  scanner.  The  halftone  file 
goes  directly  to  the  consolidated  data  base.  The  line 
art,  after  scanning,  proceeds  through  a  raster/vector 
translator  to  the  CAD/CAM  Illustrator's  Workstation. 

The  line  art  data  then  follows  the  same  alternative 
paths  that  we  have  symbolized  for  basic  drawing  data 
coming  down  out  of  the  IGES  Data  File. 

This  is  the  approach  that  is  being  considered. 

This  study  is  more  or  less  halfway  through.  The  Ad  Hoc 
Group  expects  to  report  out  by  December.  It  is  our 
intention  to  present  it  to  you  to  provide  you  with  an 
awareness  of  the  fact  that  the  Logistics  people  and  the 


Technical  Publications  people  are  working  together  very 
closely  on  this  and  to  invite  any  comments, 
observations,  criticisms,  suggestions,  modifications 
that  you  may  wish  to  present  in  oral  or  written  form 
concerning  IGES,  GKS,  SGML,  or  other  dimensions. 

Do  you  have  any  questions  that  you  would  like  to 
pose  or  any  observations? 


iuestion 


Do  you  see  one  of  the  results  of  this  system  as 
linking  that  data  into  the  LSA  and  LSAR  systems? 


Answer 

The  goal  of  the  Logistics  people  is  to  come  out 
with  a  master  system  that  will  incorporate  all  of  the 
elements  of  LSA.  You  know  from  what  you’ve  heard  here, 
that,  if  there  is  a  data  element,  it  can  be  identified 
using  the  techniques  of  SGML.  If  you  have  the  data 
element  identifier  on  it,  you  have  the  hooks  into  which 
you  can  connect  to  move  this  data  out  for  Technical 
Documentation  purposes  or  for  Logistics  purposes.  The 
real  thrust  of  this  is  the  interchangeability  of  this 
data  between  a  supplier  and  the  customer  —  for 
example,  DoD,  or  to  have  DoD  give  this  out  to  somebody 
else  to  perform  some  other  task  on  the  data  that  they 
may  wish  to  have  performed  ....  either  internally 
within  DoD  activities  or  externally  by  a  contractor  who 
has  been  engaged  to  provide  these  supplementary 
services.  The  real  goal  is,  as  you  have  perceived,  not 
to  have  parallel  systems,  but  rather  to  maximize  the 
multiplicity  of  use  of  the  same  data.  This,  of  course, 
has  the  obvious  benefit  that  you  only  change  data  in 
one  place.  You  aren’t  as  vulnerable  to  tracking  two  or 
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more  systems  to  keep  the  numbers  the  same  for  the 
changes  you’ve  made. 


Answer 

We  can  provide  you,  from  GCA,  a  certain  minimal 
amount  of  this  material,  particularly  with  regard  to 
those  specific  areas  of  the  study  with  which  we  are 
concerned.  I  would,  however,  make  two  cautionary 
observations.  It  will  not  be  official,  and  it  will  not 
necessarily  be  the  study  result  which  will  come  along 
in  December.  We  will  be  pleased  to  make  study  results 
available  when  it  has  been  officially  issued  just  as  we 
will  be  pleased  to  provide  preliminary  information  at 
any  time  in  the  course  of  the  study. 
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EPILOGUE:  READERS'  CAVEAT 


The  description  given  above  of  a  proposed 
recommendation  for  further  study  and  pilot 
implementation  is  a  GCA  submission.  It  is  not 
"official.”  It  does  not  necessarily  reflect  the  views 
or  position  of  The  National  Bureau  of  Standards,  The 
Technology  Issues  Subgroup,  The  Ad  Hoc  Group  on 
Computer-Aided  Logistics  Support,  nor  of  The  Institute 
for  Defense  Analyses.  It  is,  rather,  in  the  nature  of 
an  "individual  contribution"  submitted  for 
consideration  and  possible  use. 

The  Reader  is  referred  to  the  Final  Report,  when 
issued,  for  accepted,  official  positions  and 
recommendations. 


*  =  A  Trademark  of  GCA 

IGES  =  Initial  Graphics  Exchange  Specification 

GKS  =  Graphic  Kernel  System 

VDM  =  Virtual  Device  Metafile 

VDI  =  Virtual  Device  Interface 
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TECHNOLOGY  AND  STANDARDS  ISSUES 
RELATED  TO  COMPUTER-AIDED  LOGISTICS 

Robert  J.  Hocken,  Chief 
Automated  Production  Technology  Division 
Center  for  Manufacturing  Engineering 
National  Bureau  of  Standards 

September  12,  1984 

1.0  INTRODUCTION 

In  order  that  CALS  program  objectives  be  met,  it 
is  essential  that  a  complete  spectrum  of  standards  be 
adopted  or  developed.  This  spectrum  of  standards  must 
include  at  least  the  following: 

o  Data  base  standards  —  this  includes 
standard  methodologies  for  archiving 
and  retrieval  of  digital  data  in 
large  volume.  In  particular,  stan¬ 
dardization  of  the  software  tools  to 
manage  and  control  complex  data  des¬ 
criptions  is  essential.  These  so- 
called  data  dictionary  systems  must 
be  standardized  for  a  fully  success¬ 
ful  logistics  program  in  this 
computer  era.  (The  NBS  specifica¬ 
tions  for  a  "Core"  data  dictionary 
system  is  an  example  here.) 

o  Communications  standards  —  here  what 
is  required  are  the  standards  that 
allow  implementation  of  the  ISO  Open 
Systems  Interconnection  Model  for 
network  communications,  either 
locally  or  over  extended  distances, 


between  an  extremely  wide  variety  of 
computer  systems.  (The  NBS/GM  MAP 
Protocol  is  an  example  here.) 

Product  definition  standards  —  these 
standards  refer  to  common,  computer 
system  independent,  methods  for  pro¬ 
viding  the  complete  description  of 
the  required  product.  This  descrip¬ 
tion  must  be  sufficiently  complete  so 
that  the  data  supplied  are  sufficient 
for  remanufacture  by  different 
facilities  over  extended  periods  of 
time.  (IGES  and  its  extensions  is  an 
example  here.) 

Graphics  standards  —  a  requirement 
here  is  for  the  standards  necessary 
for  the  archiving  of  graphic  images 
as  well  as  the  standards  necessary 
for  allowing  graphics  manipulation. 
(Here  VDM  is  an  example  of  a  graphics 
archiving  data  format,  and  GKS  is  an 
example  of  a  manipulative  language 
standard. ) 

Textual  standards  —  here  the 
requirement  is  for  both  a  standard 
means  of  storing  textual  data  and  a 
standard  means  for  tagging  such  data 
with  textual  constructs.  (ASCII  code 
is  a  reasonable  example  for  the  char¬ 
acter  set  storage,  while  GenCode 
(SGML)  is  an  example  of  the  language 
which  allows  the  tagging  of  textual 
and  other  entities  for  document  pre¬ 
paration.  ) 


The  above  listing  represents  a  minimal  set  of 
standards  that  will  be  required  for  a  successful  imple¬ 
mentation  of  a  Defense  Department-wide  Computer  Aided 
Logistics  System.  In  the  following  text  each  of  these 
standards  opportunities  will  be  described  briefly. 

2.0  DATA  BASE  STANDARDS 

An  integrated  computer-aided  logistics  support 
capability  will  require  standardized  mechanisms  for 
defining  and  controlling  data.  A  data  dictionary  sys¬ 
tem  is  a  software  tool  to  manage  and  control  complex 
data  descriptions.  Data  dictionaries  allow  program¬ 
mers,  analysts,  data  base  administrators,  and  others  to 
understand  and  control  the  data  that  are  in  the  system. 
They  reduce  maintenance  costs  over  the  total  life  of  a 
system,  while  allowing  for  planning,  designing,  docu¬ 
menting,  and  providing  quality  control  for  information 
resources.  The  data  dictionary  is  also  useful  for 
providing  data  descriptions  to  a  data  base  management 
system  or  other  software  system.  Thus,  a  functionaly 
complete  data  dictionary  system  can  serve  as  a  logical 
integrator  throughout  the  total  life  cycle  of  an  infor¬ 
mation  system.  Although  data  dictionary  systems  are  in 
their  infancy,  programs  are  ongoing  around  the  world  to 
develop  standards  for  the  most  commonly  used  (or  core) 
capabilities  of  a  data  dictionary  system.  These 
efforts  are  expected  to  lead  to  an  American  National 
Standard  in  the  1985  time  frame  within  the  United 
States.  It  is  essential  to  the  CALS  program  that  these 
efforts  be  supported  and  that  a  standardized  detailed 
design  for  an  external  interface  to  a  data  dictionary 
system  for  CALS  be  implemented. 

Another  issue  which  will  be  of  increasing  impor¬ 
tance  to  the  CALS  program  is  that  of  being  able  to 


handle  distributed  data  base  systems.  Distributed  data 
bases  are  still  extremely  poorly  understood  as  few  have 
been  attempted  in  real  situations.  The  architecture  of 
such  distributed  data  bases  is  also  strongly  dependent 
upon  the  inter-system  communication  constraints  which 
will  be  discussed  below,  under  Communications  Stan¬ 
dards.  At  this  time,  distributed  data  bases  or  admin¬ 
istration  systems  represent  a  technical  rather  than  a 
standards  issue,  as  several  years  of  concentrated  re¬ 
search  will  be  required  in  this  critical  area  before 
standards  priorities  can  be  identified. 

3.0  COMMUNICATIONS  STANDARDS 

Any  realistic  CALS  system  will  obviously  consist 
of  computers  and  data  bases  from  multiple  vendors 
located  at  geographically  widely  varying  sites  with 
many  locally  different  needs  and/or  applications.  In 
order  that  such  a  structure  be  viable,  current  thought 
is  that  a  complete  hierarchy  of  network  communications 
standards  will  have  to  be  developed.  Here  the  world¬ 
wide  target  is  the  Open  Systems  Interconnection  Model 
(OSI)  where  there  are  extensive  ongoing  activities, 
such  as  the  industry  government  consortium  on  the  so- 
called  MAP  program.  Since  such  communication  is  essen¬ 
tial  to  CALS  a  significant  effort  should  be  made  to 
both  understand  and  support  this  important  standards 
development . 

4.0  PRODUCT  DEFINITION  STANDARDS 

Current  product  definition  standards  are  confined 
to  standards  for  data  file  formats  which  contain,  in 
principle,  all  the  information  necessary  for  product 
manufacture.  Here  the  chief  standard  activity  is  based 
around  IGES  and  its  successors,  which  will  probably  be 
given  new  names.  As  currently  constituted,  IGES  is 
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relatively  complete  for  the  wire  frame  definition  of 
mechanical  parts,  i.e.,  it  is  capable  of  archiving  and 
transmitting  within  multi-vendor  systems  the  equivalent 
of  a  mechanical  drawing.  IGES  is,  however,  like  any 
public  domain  data  format,  dependent  upon  vendor 
ability  to  translate  from  internal  representations  into 
this  format,  thus  considerable  work  needs  to  be  done  in 
order  to  verify  and  validate  existing  IGES  translators. 
Furthermore,  for  mechanical  parts,  the  expansion  of  the 
IGES  into  true  solid  modeling  is  essential.  Although 
the  technical  work  has  been  done,  efforts  are  needed  to 
convert  these  early  efforts  into  complete  standards. 
Besides  these  efforts,  IGES  must  be  expanded  into  other 
application  areas  in  order  to  meet  CALS  objectives. 
These  areas  includd  architectural  engineering,  plant 
design,  printed  circuit  board  design,  cabling  and 
hardness  specifications,  and  integrated  circuit  defini¬ 
tion.  Efforts  in  this  area  are  ongoing  but  require 
expediting. 

5.0  GRAPHICS  STANDARDS 

Over  the  past  few  years  many  different  proposed  or 
actual  graphics  standards  have  emerged.  The  most 
important  of  these  for  the  CALS  program  are: 

o  Grahical  Kernel  System  (GKS)  —  a 
proposed  ANSI  Standard  addressing  2D 
graphics  functions  for  computer  pro¬ 
grammers  . 

o  CORE  —  a  defacto  standard  addressing 
2D  and  3D  graphics  functions  for  com¬ 
puter  programmers. 

o  Programmers  Hierarchical  Interface  to 
Graphics  (PHIGS)  —  a  proposed  ANSI 
Standard  addressing  3D  graphics 


102 


functions,  aimed  at  applications 
requiring  very  high  performance  and 
increased  user  interaction. 

o  Virtual  Device  Metafile  (VDM)  —  a 
proposed  ANSI  Standard  aimed  at  de¬ 
veloping  data  files  for  transporting 
graphics  pictures  between  different 
devices.  It  is  intimately  related  to 
GKS  discussed  above. 

o  North  American  Presentation  Level 

Protocol  Standard  (NAPLPS)  —  an  ANSI 
Standard  for  defining  and  storing 
computer  graphics  information  primar¬ 
ily  for  video  text  applications. 

This  standard  is  probably  most  useful 
for  long-term  CALS  applications  where 
data  are  transferred  to  video  termi¬ 
nals  in  the  field. 

o  Virtual  Device  Interface  (VDI)  —  a 
proposed  ANSI  Standard  which  defines 
the  interface  between  independent 
graphics  software  and  device¬ 
dependent  drivers. 

Each  of  these  standards  is  intended  for  a  dif¬ 
ferent  purpose  and  is  aimed  at  a  distinct  constituency. 
The  principle  overlap  above  consists  between  GKS  and 
CORE,  with  GKS  currently  having  the  broader  user  base 
support.  Current  conception  of  the  CALS  program  will 
probably  require  support  in  all  these  areas  in  order 
that  sufficient  options  be  available  to  DoD  suppliers. 
Issues  include  the  selection  of  appropriate  standards, 
testing  for  conformance  to  these  standards,  testing  the 
standards  for  performance,  and  standardizing  the 
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interface  between  graphics  and  other  software  tools, 
such  as  data  base  management  systems  and  the  textual 
standards  mentioned  below. 

6.0  TEXTUAL  STANDARDS 

Standards  considerations  in  the  textual  area  must, 
by  necessity,  include  both  the  ability  to  transmit 
simple  textual  data  between  multiple  textual  processing 
systems,  as  well  as  incorporating  standardized  methods 
for  defining  textual  and  graphical  elements  for  the 
creation  of  technical  publications.  The  system  must  be 
capable  of  both  interfacing  with  the  paper  world  for  a 
period  of  many  years,  as  well  as  providing  digital  com¬ 
munications  where  such  facilities  exist.  Thus,  it 
appears  to  be  essential  to  have  a  standardized  charac¬ 
ter  representation  which  could  be  used  throughout  the 
CALS  program  (perhaps  such  a  simplistic  representation 
as  DIF  for  primitive  communication  between  word  proces¬ 
sors)  as  well  as  a  higher  level  textual  control  stan¬ 
dard  like  SGML  (GenCode).  GenCode  also  allows  the 
incorporation  of  graphical  entities  into  textual  struc¬ 
tures  as  is  outlined  in  a  separate  document  by  William 
Tunnicliffe  in  his  report  to  this  Committee. 

7.0  RECOMMENDATIONS 

Given  the  above  issues  and  considerations,  ray  cur¬ 
rent  thoughts  are  that  CALS  should  sponsor  the  follow¬ 
ing  course  of  action. 

o  Assembling  of  a  team  with  representa¬ 
tives  from  the  various  standards 
efforts  related  to  CALS  to  delineate 
more  fully  the  technical  issues, 
report  in  detail  on  current  standards 
contents,  provide  detailed  time 


frames,  and  assess  the  expansion 
capabilities  within  the  various 
areas.  Such  a  team  should  include 
representatives  from  the  Department 
of  Defense  standards  organizations, 
trade  associations,  as  well  as  repre¬ 
sentatives  from  the  principle 
national  standards  body,  i.e.,  the 
National  Bureau  of  Standards. 

Simultaneously  with  the  above,  choose 
several  target  areas  to  expedite  im¬ 
mediately.  Here  the  idea  would  be  to 
streamline  the  existing  standardiza¬ 
tion  efforts  and  to  develop  verifica¬ 
tion  and  validation  procedures  and 
methods.  Obvious  candidates  must 
include  IGES  for  the  product  data 
definition  file  formats,  VDM  for  the 
graphics  data  file  formats,  GKS  for 
graphics  manipulation,  and  SGML  for 
textual  definition. 

Initiate  development  efforts  in  the 
areas  of  standardized  data  diction¬ 
aries  and  distributed  data  base 
systems  using  the  appropriate  techni¬ 
cal  resources,  either  within  the 
Government  or  private  industry. 

Sponsor  and/or  facilitate  ongoing 
efforts  in  network  standardization. 

Of  particular  concern  here  is  to 
develop  detailed  definitions  for  the 
areas  between  the  Application  level 
of  the  Open  Systems  Interconnection 


Model  and  the  lower  levels  which  are 
being  implemented  currently. 


o  Obtain  appropriate  expertise  for 

defining  the  architecture  for  a  com¬ 
plete  CALS  system  in  order  that  this 
architecture  be  used  for  the  guidance 
of  future  standards  and  technical 
development  activities. 
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ABSTRACT 

The  Initial  Graphics  Exchange  Specification  (IGES) 
program  coordinates  the  efforts  of  over  60  companies  in 
the  development  and  documentation  of  a  means  for 
graphics  data  base  exchange  among  present  day  CAD/CAM 
systems.  The  project's  brief  history  has  seen  the 
evolution  of  the  Specification  from  technical  develop¬ 
ment  into  actual  industrial  usage.  Highlights  of  the 
development  process  have  been  public  demonstrations  of 
vendor  capability,  the  inclusion  of  mandatory  requests 
for  IGES  capability  in  procurement  actions,  the 
formalization  of  the  Specification  into  American 
National  Standard  (ANSI)  Y14.26M,  and  the  beginning  of 
an  effort  in  the  international  standards  area.  To 
date,  seventeen  vendor  systems  have  successfully 
exchanged  IGES  files  in  public  tests  of  capability,  and 
over  thirty  vendors  have  committed  to  offer  IGES  capa¬ 
bility.  A  full  range  of  documentation  supports  the 
IGES  project,  the  most  recent  of  which  is  Version  2.0 
of  the  Specification. 


INTRODUCTION 

Today  all  industrialized  nations  of  the  world  are 
being  challenged  to  increase  productivity  in  the  design 
and  manufacture  of  products.  At  the  same  time,  they 
must  face  problems  of  increased  product  complexity  and 
shortened  product  life  cycles.  The  development  and 
growth  of  computer-aided  design  and  manufacturing, 
commonly  known  as  CAD/CAM,  provided  a  partial  solution 
to  these  productivity  problems. 

However,  as  more  and  more  users  turned  to  CAD/CAM 
equipment  to  increase  their  productivity,  they  realized 
that  the  full  potential*  of  this  equipment  could  not  be 
met  without  a  method  for  communicating  data  between 
different  systems. 

In  September  1979  representatives  from  government 
and  industry  joined  forces  under  the  Air  Force  ICAM 
program  to  develop  this  method  for  data  exchange. 
Funding  for  management  and  coordination  was  provided  by 
the  Army,  Navy,  Air  Force,  and  NASA  through  the  ICAM 
program.  Industrial  users  and  CAD/CAM  system  suppliers 
provided  resource  material  and  personnel. 

Development  of  the  data  exchange  method  was 
assigned  to  a  technical  committee  with  representatives 
from  the  National  Bureau  of  Standards  (NBS),  the 
General  Electric  Company,  and  the  Boeing  Company  with 
coordination  for  the  overall  effort  assigned  to  NBS. 

The  result  of  this  industry-wide  effort  was  the 
creation  of  the  Initial  Graphics  Exchange  Specifica¬ 
tion,  known  as  IGES,  which  was  first  published  in 
January  1980  as  an  NBS  report  and  approved  as  an  ANSI 
Standard  (Y14.26M)  in  September  1981. 

Just  what  is  IGES  and  how  can  it  increase  produc¬ 
tivity  for  your  organization?  IGES  is  a  data  format 
for  describing  product  design  and  manufacturing  infor- 


mation  which  has  been  created  and  stored  in  a  CAD/CAM 
system  in  computer-readable  form.  The  IGES  format  is 
in  the  public  domain  and  is  designed  to  be  independent 
of  all  CAD/CAM  systems. 

The  benefit  of  this  common  format  is  that  a  user 
does  not  have  to  develop  special  translators  for  each 
different  piece  of  equipment  that  is  used.  The  only 
requirement  is  to  have  a  translator  to  and  from  the 
IGES  format.  These  translators,  called  pre-  and  post¬ 
processors,  are  generally  available  from  the  equipment 
vendor.  In  addition,  an  IGES  file  can  be  stored  on 
magnetic  tape  or  disk  memory  for  future  use.  It  can  be 
transmitted  between  systems  via  telecommunications. 


Translator  Development 

The  ultimate  goal  of  the  IGES  project  is  to  allow 
portability  of  data  among  dissimilar  CAD/CAM  systems. 
Certainly  the  development  of  a  national  standard  is  a 
major  step  toward  that  goal.  But  portability  will  not 
be  realized  until  quality  translator  implementations 
are  in  widespread  use.  Recent  events  have  contributed 
much  toward  this  goal  from  both  a  user  and  a  vendor 
standpoint . 


Many  users  of  CAD/CAM  systems  have  already 
invested  heavily  in  the  development  of  special  purpose 
software  for  the  design,  analysis  and  testing  of  their 
discrete  products.  As  they  seek  to  integrate  this 
software  into  total  design  and  manufacturing  systems, 
many  are  making  use  of  IGES  to  solve  their  problems  of 
data  base  communications.  The  work  has  a  dual  focus: 
transfer  of  product  definition  data  within  the 
corporate  system  and  digital  communication  between  the 
company  and  its  suppliers  and  customers. 
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From  the  inception  of  the  IGES  project,  the 
graphics  vendor  community  has  provided  good  technical 
support  toward  its  development.  Currently,  vendors 
have  either  demonstrated  their  capability  or  have 
supplied  sample  files  for  testing.  Around  forty 
vendors  are  now  committed  to  supplying  IGES  translators 
for  their  products.  The  top  five  CAD/CAM  vendors  of 
1983  (determined  by  volume  of  sales)  all  offered  IGES 
capability.  Figure  1  presents  this  information  on 
vendor  implementations. 


Intersystem  Testing 

The  first  opportunity  for  exchange  of  IGES  files 
among  different  computer  systems  occurred  in  the  fall 
of  1981  with  the  publication  of  the  Test  Library.  Thi3 
dodument  and  accompanying  magnetic  tape  contain  36 
individual  test  cases  of  IGES  entities. 

In  December  1 98 1  the  first  publicly  documented 
intersystem  transfer  of  IGES  information  in  an  actual 
working  environment  occurred  between  two  operating 
facilities  of  the  Department  of  Energy  (DoE).  A 
mechanical  part  was  designed  and  detailed  on  a 
Computervision  CADDS  4  system  located  at  Sandia 
National  Laboratories  in  Livermore,  California.  Three- 
dimensional  model  data  describing  the  geometry  of  this 
part  was  expressed  in  the  IGES  format  on  magnetic  tape 
and  transported  to  the  Bendix  Corporation  in  Kansas 
City,  MO.  There  it  was  interpreted  on  the  Control  Data 
Corporation  CD  2000  system  where  data  was  added  to 
define  a  cutter  path  for  subsequent  NC  machining.  A 
production  print  from  Sandia  was  used  during  final 
inspection  to  verify  part  accuracy.  The  IGES  tran¬ 
slators  used  were  commercially  available,  vendor  sup¬ 
plied  standard  pre-  and  post-processors. 


The  first  public  test  of  IGES  data  exchange 
capability  took  place  in  June  1982  at  the  NCGA 
Exposition  in  Anaheim,  California.  The  three- 
dimensional  geometry  of  the  mechanical  part  from  DoE 
was  used  for  the  tests.  Additional  geometry  was  added 
to  the  part  with  the  resulting  file  being  written  out 
on  an  IGES  tape.  This  tape  was  carried  to  the  next 
vendor  where  it  was  read  in  and  displayed  on  the 
screen.  Changes  to  the  model  geometry  were  made  at 
each  site  and  could  be  seen  at  all  successive 
locations. 

The  AUTOFACT  4  conference  and  exposition  held  in 
the  fall  of  1982  provided  the  next  opportunity  for 
public  demonstration.  Five  graphics  vendors  partici¬ 
pated  in  that  demonstration.  Preparations  for  this 
test  of  IGES  processors  started  with  part  geometry 
developed  by  the  IGES  Test,  Evaluate  and  Support 
Committee.  Figure  2  is  a  screen  copy  of  the  original 
test  part  which  contained  the  full  range  of  dimension¬ 
ing  needed  for  communicating  engineering  drawings. 

A  more  complex  test  was  performed  at  the  AUTO¬ 
FACT  5  conference  in  November  1983-  The  starting  file 
for  this  IGES  data  exchange  test  contained  the  three- 
dimensional  wire  frame  geometry  of  a  complicated 
mechanical  part  together  with  typical  dimensioning  and 
annotation  on  three  views.  The  original  geometry  was 
developed  by  the  CAM-I  Geometric  Modeling  Project  and 
was  translated  into  IGES  format  at  McDonnell 
Automation.  Annotation  and  dimensions  were  added  to 
the  file  at  Bendix.  Hughes  Corporation  provided  final 
editing  to  the  test  file  and  distributed  it  to 
AUTOFACT  5  test  participants.  Figure  3  shows  a  dimen¬ 
sioned  view  of  the  part.  The  twelve  vendors  who  parti¬ 
cipated  in  that  demonstration  were  Applicon,  Auto-trol, 
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Bausch  &  Lomb,  CALMA,  Control  Data,  Computervision, 
Gerber,  Graftek,  Matra  Datavision,  McAuto  Unigraphics, 
MCS,  Inc.,  and  Prime-Medisa.  Union  Carbide,  Oak  Ridge, 
machined  the  part  from  an  IGES  file.  That  part  and  a 
copy  of  the  results  of  the  test  were  on  display  at  the 
IGES  exhibit. 

Plans  for  the  AUTOFACT  6  exposition  include  an 
IGES  test  among  14  vendors.  Four  new  vendors  are 
expected:  Hewlett/Packard,  InterCAD,  SDRC,  and 
CADLINC.  Although  the  geometry  of  the  AUTOFACT  6  test 
in  October  1984  is  similar  to  that  used  in  1983,  the 
data  content  is  significantly  more  complex.  An 
improved  drawing  and  view  entity  structure  developed 
for  Version  2.1  of  IGES  has  been  incorporated  into  the 
test.  This  cleanly  separates  the  model  geometry  from 
display  characteristics  such  scale,  view  and  annota¬ 
tion.  Conics  in  the  model  geometry  are  expressed  in 
standard  form  to  alleviate  prior  instability  problems. 
Dimensions  include  upper  and  lower  tolerance  limits  and 
often  make  use  of  multiple  font  codes.  Finally, 
special  feature  control  symbols  are  included  for 
squareness,  concentricity  and  parallelism. 

The  IGES  Organization 

To  accomplish  the  IGES  goal,  a  committee  structure 
has  been  established  under  the  leadership  of  NBS. 
Overall  policy  and  direction  are  provided  by  the 
Steering  Committee  which  is  chaired  by  the  member  from 
the  National  Bureau  of  Standards.  Other  Steering  Com¬ 
mittee  members  are  management  personnel  from  four  dif¬ 
ferent  interest  sectors:  military/government, 
suppliers  of  CAD/CAM  systems,  industrial  users  of 
CAD/CAM  systems,  and  members  at-large. 
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Reporting  to  the  Steering  Committee  are  the 
Extensions  and  Repairs  (E&R)  and  Test,  Evaluate  and 
Support  (TE&S)  Committees.  The  majority  of  the 
technical  work  on  the  project  is  done  by  a  series  of  17 
subcommittees  under  these  two  committees. 

The  E&R  Committee  has  primary  responsibility  for 
the  technical  quality  of  the  Specification  and  as  such, 
deals  with  all  changes  and  additions.  Its  subcommit¬ 
tees  are  active  in  areas  of  advanced  geometry,  finite 
element  modeling,  electrical/electronics,  plant  design, 
architecture-engineering  and  construction,  manufactur¬ 
ing,  and  drafting.  In  addition,  the  E&R  Committee  is 
responsible  for  the  work  which  produced  Version  2.0  of 
IGES  and  will  produce  its  enhanced  version,  2.1,  due  to 
be  published  in  early  1985. 

The  TE&S  Committee  has  primary  responsibility  for 
providing  the  tools  to  ensure  the  development  of 
quality  translator  software.  It  provides  assistance  to 
implementors  including  technical  review  of  implementa¬ 
tions,  resolution  of  problems  encountered,  and  the 
general  exchange  of  information  in  support  of  the  over¬ 
all  implementation  of  IGES. 

One  of  the  first  products  of  this  committee  was 
the  IGES  Test  Library  mentioned  earlier.  In  addition, 
it  is  developing  a  Recommended  Practices  Guide  to  serve 
as  an  aid  for  future  implementors  by  providing  descrip¬ 
tions  of  generally  accepted  alternatives  to  common  IGES 
issues.  The  guide  will  further  serve  to  establish  a 
general  philosophy  for  IGES  implementations.  When  this 
committee  discovers  ambiguous  or  erroneous  areas,  it 
forwards  issues  which  require  resolution  within  the 
IGES  Specification  to  the  E&R  Committee. 
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Meetings  as  a  whole  of  the  E&RD  and  TE&S  Commit¬ 
tees  are  used  for  dissemination  of  information  and  for 
balloting  on  the  work  of  their  various  subcommittees. 

Version  2.0 

IGES  Version  2.0  was  published  in  early  1983  as 
both  a  refinement  and  an  extension  of  earlier  published 
works.  Clarity  and  precision  of  the  Specification  were 
dramatically  improved  as  the  result  of  wider  public 
review  and  comment  plus  feedback  from  an  ever- 
increasing  amount  of  implementation  and  testing.  In 
addition,  many  extensions  and  enhancements  were  incor¬ 
porated  in  the  Specification  to  expand  its  capability 
to  communicate  a  wider  range  of  product  data  developed 
and  used  by  computer-aided  design  and  manufacturing 
systems.  Despite  these  extensions  and  enhancements, 
Version  2.0  remained  nearly  upward  compatible  with 
Version  1.0.  The  only  exception  i3  a  change  in  the 
Text  Font  Definition  entity.  The  Version  2.0  document 
was  approved  in  July  1982  by  the  IGES  committee  struc¬ 
ture  and  published  as  NBSIR  82-2631 (AF)  in  February, 
1983. 

Users  of  Version  2.0  of  the  IGES  Specification 
will  be  pleased  to  see  the  many  technical  extensions 
which  have  been  added  to  augment  its  capability  and 
expand  it  into  new  areas.  Many  geometric  entities  have 
been  enhanced  in  scope  to  be  more  generally  applicable. 
Included  here  are  the  parameterization  in  the  Ruled 
Surface  entity,  a  more  general  form  of  the  Tabulated 
Cylinder  entity,  and  the  means  of  relating  the  Surface 
of  Revolution  entity  to  the  common  geometrical  surfaces 
like  spheres  and  cones. 

Two  new  geometry  entities,  a  Rational  B-Spline 
Surface  entity  and  a  related  Rational  B-Spline  Curve 
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entity,  were  added  in  Version  2.0.  The  addition  of 
these  entities  provided  a  much  more  general  approach 
for  surface  and  curve  representation.  New  structural 
entities  were  also  developed  and  documented  for  both 
rectangular  and  circular  arrays  of  geometric  entities. 

In  the  annotation  area.  Version  2.0  improved  on 
the  earlier  work  by  specifying  a  much  larger  set  of 
text  fonts.  Improvements  were  made  in  the  clarity  of 
intent  for  positioning  and  scaling  of  text  material  and 
in  a  more  clearly  defined  Angular  Dimension  entity. 

Two  new  applications  areas  were  addressed  by 
Version  2.0:  finite  element  modeling  data  and 
electronics  printed  wiring  board  product  data.  The 
earlier  IGES  Specification  contained  no  means  of 
handling  this  data,  yet  both  are  widely  used 
applications  on  CAD/CAM  systems. 

Version  2. 1 

Work  is  nearing  completion  on  a  new  version  of 
IGES.  The  document,  called  IGES  Version  2.1,  is 
expected  to  include  additional  capability  in  the 
geometry  area,  in  references  to  external  IGES  files,  in 
expressing  the  notion  of  connectivity  in  a  far  more 
capable  MACRO  feature,  and  in  support  of  applications 
areas  such  as  finite  element  analysis  and  electronics 
products.  All  changes  for  Version  2.1  have  been 
balloted  upon  by  the  IGES  committees,  and  publication 
is  scheduled  for  early  1985. 

International  Standardization 

The  time  is  appropriate  for  the  consideration  of 
IGES  by  the  International  Organization  for 
Standardization  (ISO).  Active  information  exchange 
between  the  U.  S.  nd  other  countries  has  occurred  since 
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1981.  The  IGES  project  has  held  three  major  workshops 
in  France  and  the  United  Kingdom  and  maintains  active 
dialogue  with  groups  in  France,  UK,  Canada  and  Germany. 
The  German  DIN  organization  and  the  French  SET  project 
made  presentations  to  the  IGES  meeting  in  February  1984 
concerning  closer  cooperation.  The  UK  has  a  parallel 
group  aplying  IGES  to  the  Plant  Design  area. 

As  the  first  step  in  the  official  international 
standards  process,  ISO  voted  in  December,  1983,  to  set¬ 
up  a  technical  committee  on  industrial  automation  and 
to  create  a  special  subcommittee  on  the  external 
representation  of  product  definition  data.  As  the 
first  work  item  for  this  subcommittee,  the  U.  S. 
delegation  submitted  the  IGES  document. 

A  first  meeting  of  the  subcommittee  was  held  at 
NBS  in  July  1984  with  delegations  from  six  countries  in 
attendance.  Unanimous  agreement  was  obtained  on  the 
need  for  a  single  international  standard  for  data 
exchange.  Functional  capability  of  the  standard  was 
identified,  and  an  aggressive  schedule  of  work  was 
defined . 

For  More  Information 

A  great  variety  of  formal  documentation  exists  to 
describe  the  IGES  Specification  and  its  application  to 
CAD/CAM  processes.  Figure  4  lists  this  documentation 
as  well  as  information  for  ordering  the  various  items. 
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SUMMARY 

Many  organizations  are  anticipating  the  use  of  new 
and  improved  CAD/CAM  systems  in  an  integrated  fashion 
to  achieve  productivity  gains.  As  you  can  see,  IGES 
provides  a  way  to  achieve  that  integration.  It  holds 
great  potential  as  a  common  communications  format  among 
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automated  functions  in  design,  engineering  analysis, 
manufacturing,  and  part  inspection.  Additionally,  it 
may  serve  as  a  vehicle  for  meaningful  communication  of 
product  definition  data  among  different  companies  over 
the  full  lifetime  of  a  product. 

In  the  future,  additional  CAD/CAM  applications 
will  be  demanded  by  users.  A  standardized 
communications  interface  will  be  essential  among  the 
various  modules  of  a  CAD/CAM  system  —  essential  if 
these  systems  are  to  be  flexible  enough  to  adapt  to 
changing  priorities  and  essential  if  users  are  to 
•realize  the  full  potential  of  their  equipment.  IGES 
provides  that  interface. 

The  present  Specification  is  well  developed  and 
tested  and  is  further  strengthened  by  the  wide  range  of 
supporting  technical  literature  —  all  of  which  is  in 
the  public  domain.  Its  data  exchange  technique  is  well 
supported  by  the  vendor  community.  It  has  been  seen 
approved  as  an  American  National  Standard  and  submitted 
for  recognition  as  an  international  standard.  While 
the  current  IGES  does  not  solve  all  CAD/CAM  data 
exchange  problems,  it  goes  a  long  way  toward  solving 
users*  current  data  exchange  problems  and  has  the  capa¬ 
bility  of  being  extended  to  meet  the  needs  of  this 
growing  and  maturing  field. 


PDBLICALLY  DEMONSTRATED 
IGES  VENDOR  IMPLEMENTATION 
IN 

INTERSYSTEM  DATA  EXCHANGE 


APPLICON 
AUTOTROL 
BAUSCH  &  LOMB 
CADLINC 
CALMA 

COMPUTERVISION 
CONTROL  DATA 
GERBER 
GRAFTEK 

HEWLETT/PACKARD 
IBM  CADAM 
InterCAD 

MATRA  DATAVISION 
MCAUTO  UNIGRAPHICS 
MCSI 

PRIME  MEDUSA 
SDRC 


Figure  1 
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IGES  DOCUMENTATION 


1.  +Technical  Briefing  (NTIS  Order  No.  PB  81-238719) 


2.  +Version  2.0  (NTIS  Order  No.  PB  83-137448) 


3.  oANSI  Y 14. 26M  (Order  No.  N000-99) 


4.  *IGES  Test  Library 


5.  *MACR0  Software  Manual 


6.  *IGES  Newsletter 


7.  *Meeting  Announcements 


AVAILABILITY 


•IGES 

National  Bureau  of  Standards 
Building  220,  Room  A-353 
Washington,  D.  C.  20234 

oASME 

United  Engineering  Center 
345  E.  47th  Street 
New  York,  NY  10017 
Attns  Publication 
(212)  705-7703 

♦National  Technical  Information  Service  (NTIS) 
5285  Port  Royal  Road 
Springfield,  VA  22 1 6 1 
(703)  487-4650 

Figure  4 
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FOREMAN'S  CONCEPT  A_ 
LOGISTICS  TOOLS:  CREATION  VS.  USE 


THREE  LEVELS  OF  LOGISTICIANS 

1.  Pre-Conceptual  -  Tool  Creation 

2.  Conceptual  -  Tool  Selection 

3.  Practitioner  -  Tool  Use 

1.  PRE-CONCEPTUAL  LOGISTICIAN  —  THE  TOOL  KIT 

PROVIDER 

o  Performs  real  logistics  R&D 
o  Determines  true  cause/effect  relationships 
o  Develops  logistics  tools  —  dynamic 
models,  etc. 

o  Develops  tool  application  "cookbooks” 
o  Works  "outside"  the  acquisition  process, 
i.e.,  in  generic  world,  not  specific 
program 

o  Creates  logistics  technology  base. 

2.  CONCEPTUAL  LOGISTICIAN  —  THE  LOGISTICS 
PLANNER 

o  Selects  tools  applicable  to  peculiarities 
of  new  acquisition 
o  Creatively  design  support  system 
o  Integrates  support  system  design  with 
system  design 

o  Provides  "roadmap"  for  logistics  program. 
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3.  PRACTICING  LOGISTICIAN  —  THE  TOOL  USER 
o  Applies  tools  in  day-to-day  program 
activity 

o  Carries  out  the  logistics  program  IAW 

’'roadmap”  and  tool  application  "cookbooks” 
o  Provides  experience  data  feedback  for  tool 
refinement/new  tool  development. 


CONCEPT:  CANNOT  ACCOMPLISH  LEVELS  2  and  3  UNLESS  LEVEL 
1  IS  PERFORMED  (CREATION  BEFORE  USE). 


FORENANM'5  COMCEPT  K  -  logist\cs  TOOLS 
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ACCESS  CONTROL,  MANAGEMENT  AND 
INTEGRITY  OF  INFORMATION 


The  control  and  management  of  access  to 
information  and  of  the  integrity  of  that  information  is 
a  major  issue  facing  the  coming  information  society. 
These  loom  as  particularly  important  issues  when 
considering  the  many  and  varied  DoD  logistics  suppliers 
and  the  DoD's  need  for  rapid  access  to  logistics 
support  information  around  the  globe. 

Access  control  and  management  is  concerned  with 
the  creation,  reference,  update  and  deletion  of 
information,  and  the  management  of  the  system  which 
controls  who  performs  these  various  functions.  In  the 
case  of  DoD  logistics  information,  it  is  contained  in 
various  data  bases  around  the  world.  A  data  base  is  a 
collection  of  interrelated  files  of  information 
together  with  a  description  of  the  set  of  files,  of  the 
links  between  those  files,  and  of  the  integrity 
constraints  that  apply  to  these  files.  Logistics  data 
bases,  owned  either  by  the  government  or  by  government 
contractors,  often  take  differing  forms.  However, 
accesses  to  these  data  bases,  in  either  case,  must  be 
limited  to  those  that  have  need  and  have  been 
specifically  approved  by  the  organization  who  owns  and 
by  the  organization  that  manages  the  files.  It  is 
especially  important  for  contractors  to  understand  this 
access  control  and  management.  They  must  be  in  a 
position  to  commit  proprietary  data  to  these  data  bases 
with  the  assurance  that  their  rights  will  not  be 
compromised . 


Three  requirements  are  readily  apparent  in 
considering  the  control  of  access  to  CALS  data  bases: 

a.  Personnel  with  legitimate  need  for 
information  and  authorization  to  access 
it  should  find  that  access  controls  do 
not  significantly  impede  their  access; 

b.  Personnel  with  no  need  for  the 
information  or  with  malicious  intent 
with  regard  to  the  information  should 
find  their  access  significantly  impeded; 

c.  Integrity  of  the  information  in  the 
system  should  be  verifiable  at  any  DoD 
logistics  site.  Integrity  is  defined 
and  discussed  in  following  paragraphs. 

In  other  words,  access  controls  should  not  impede 
legitimate  users  but  should  impede  (and  it  is  hoped, 
prevent)  nonlegitimate  users  in  their  attempts  to  get 
at  controlled  information.  The  second  requirement 
above  does  not,  however,  deal  with  the  secrutiy 
requirements  on  the  communications  supplied  by  DCA. 
Instead,  it  is  intended  to  address  procedures  in  using 
the  CALS  system.  Since  any  system  can  be  compromised 
with  sufficient  cost  and  effort,  various  access 
approaches  need  to  be  defined  based  on  estimated  effort 
needed  to  illegally  obtain  or  modify  information  at  the 
various  levels  within  the  CALS  system.  Again,  it  is 
critical  for  DoD  and  its  many  contractors  to  be 
satisfied  that  the  CALS  access  control  procedures  are 
adequate  for  the  information  that  they  will  protect. 

The  last  requirement  addresses  the  problem  of 
integrity  of  information  in  the  CALS  system.  The  term 
integrity  is  used  to  mean  that  information  is 
demonstrably  the  same  after  an  operation  as  it  was 


before  that  operation  (including  ’•storage" ) .  Three 
factors  appear  to  be  important  in  assuring  integrity  of 
CALS  information: 

a.  The  time  of  the  most  recent  modification 
of  the  information  can  be  determined  and 
authenticated , 

b.  The  source  of  the  information  (i.e., 
that  modification)  can  be  determined  and 
authenticated  and, 

c.  It  can  be  demonstrated  that  no  changes 
to  the  information  have  occurred  since 
the  last  modification,  either 
accidentally  or  deliberately. 

This  may  sound  like  a  tall  order,  and  it  is. 
Recently,  several  techniques  have  begun  to  appear  that 
make  it  a  reasonable  one.  These  developments  in  the 
field  of  cryptography  address  the  integrity  of 
information  as  it  is  subjected  to  transfer  —  that  is, 
communication.  The  primary  body  of  work  has  been  in 
the  development  of  the  public  key  concept.  This 
approach  to  message  integrity  recently  appeared  in  a 
proposed  standard  for  message  authentif ication  under 
ANSI  committee  X9.9.  A  similar  effort  has  seen  its 
realization  in  the  Guard  Device  (see  Sytek,  Inc.  report 
TR82001).  This  device  concept  uses  a  cryptographic 
checksum  approach  to  control  read  access  to  sensitive 
data  bases.  In  both  cases,  the  concept  is  to  control 
access  by  (1)  ensuring  that  the  information  that  is 
received  is  the  information  that  was  sent  and 
(2)  causing  unauthorized  access  to  result  in  at  most 
meaningless  data. 

The  use  of  a  cryptographic  checksum  combined  with 
the  public  key  cryptosystem  concept  can  be  used  to 
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provide  a  procedure  that  allows  the  integrity  of 
messages  to  be  easily  authenticated  by  any  person  that 
has  the  message,  the  table  of  public  keys,  and  the  two 
encryption  procedures.  The  required  manual  procedures 
for  publishing  and  maintaining  the  public  key  tables, 
the  crypto-checksum  procedures,  and  the  public  key 
crypto  procedure,  appear  developable  into  a  rational, 
reasonable,  and  useful  part  of  CALS. 

At  this  time,  neither  the  procedures  nor  the 
supporting  hardware  necessary  to  implement  access 
control  and  management  for  CALS  are  inadequate.  The 
last  two  years  of  developments  in  the  microcomputer 
industry  have  yielded  many  of  the  tools  that  will  be 
necessary  to  solve  these  problems.  Procedural  elements 
to  the  resulting  access  control  system  must  be 
carefully  formulated,  particularly  in  the  light  of 
these  new  developments  and  the  continually  evolving 
base  of  standards.  Development  of  these  procedures  is 
certainly  the  most  difficult  task  to  be  addressed  in 
establishing  access  controls  access  management  and 
information  integrity  for  DoD  logistics  support 
efforts. 


Robert  R.  Brown 
Hughes  Aircraft  Company 
(213)  616-3595 
October  1984 
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ANSI  DATA  ELEMENT  DICTIONARY 


ANSI  X12. 3-1983  and  X12. 1-1983  are  two  recent  ANSI 
documents  that  should  be  applicable  to  CALS.  More  than 
applicable,  standards  in  the  area  of  a  data  element 
dictionary  and  purchase  order  transaction  are  vital  to 
the  CALS  project. 

Careful  review  of  these  two  documents  has  led  to 
the  initial  conclusion  that  the  concepts  and  standards 
described  in  these  documents  are  cumbersome,  awkward 
and  have  no  reasonable  or  sound  theoretical  foundation 
on  which  they  are  based.  If  the  standards  were 
practical  and  easy  to  use,  the  lack  of  some  sound 
foundation  would  not  be  troublesome.  However,  the 
complex  and  laborious  standard  being  proposed  has 
little  to  recommend  it. 

A  major  concept  that  is  missing  from  the  ANSI 
documents  is  the  generic  standard  concept  that  is  so 
well  expressed  in  the  DoD  GenCode  standard.  The 
GenCode  has  a  generic  concept  allows  many  different 
implementation  specifications  within  that  concept 
depending  on  needs  in  the  various  areas  of  use.  It  is 
easy  to  modify  and  adapt,  yet  completely  workable. 
Unfortunately,  the  proposed  ANSI  standards  are  none  of 
these . 

Based  on  the  above  analysis,  it  is  strongly  urged 
that  the  technical  effort  needed  to  establish  an 
information  dictionary  and  interchange  format  be 
considered  as  the  highest  R&D  effort  for  CALS.  This  is 
an  R&D  effort  since  no  existing  conceptual  model  is 
well  accepted  by  either  the  theoretical  or  practicing 


computer  scientists  or  computer  users.  The  U3AF  IDEF1 
and  the  more  advanced  ELKA  information  model,  that  was 
developed  at  Hughes,  provides  a  sound  base  for  such  a 
standard.  However,  it  needs  more  work  in  developing  a 
generic  information  dictionary  standard  concept  and  in 
defining  various  implementation  specifications.  Other 
sound  information  models  could  also  provide  the  bases 
for  a  good  standard.  However,  like  ELKA,  none  are 
instantly  ready  to  be  made  into  a  standard. 

A  CALS  concept  based  on  the  current  ANSI  standards 
will  result  in  DoD  and  the  associated  contractors 
spending  billions  of  dollars  more  than  required  and  in 
reduced  effectiveness  to  the  entire  logistics  effort 
that  is  too  large  to  contemplate.  It  therefore,  is 
strongly  urge  that  CALS  go  forward  with  the  necessary 
recommendations  to  develop  a  new  architecture  and 
standard  in  this  vital  area. 

Robert  R.  Brown 
Hughes  Aircraft  Company 
(213)  616-3595 
October  1984 
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NETWORK  EXAMPLE 

THE  SEVEN  LAYERS  OF  THE  ISO  MODEL 


APPLICATION 

PRESENTATION 

SESSION 

TRANSPORT 

NETWORK 

DATA  LINK 


File  Transfer 
Data  Conversion 

Mailboxes 

Assembly /Disassembly 

Virtual  Circuits 
(Tele.  Switch) 

Flow  Control 


PHYSICAL 


Bits  &  Bytes 


ISO  OPEN  SYSTEMS  MODEL 

Computations 

Accounting 

Authoring 

Graphics 

Design 

Control 

APLICATION  PROCESSES 


7  APPLICATION 

6  PRESENTATION 

5  SESSION 

4  TRANSPORT 

3  NETWORK 

2  DATA  "LINK" 


1  PHYSICAL 


FUNCTIONS 


PHYSICAL  LAYER  (1) 

o  Physical  Connection  Activation  and  Deactivation 

o  Data  Unit  Transmission 

o  Management  of  Physical  Protocols 

FUNCTIONS 

DATA  LINK  LAYER  (2) 

o  Downward  Multiplexing 

o  Sequence  Control 

o  Error  Detection  and  Recovery 

o  Data  Link  Management 
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FUNCTIONS 
NETWORK  LAYER  (3) 

Internetwork  Connections 
Gateway  Management 
Error  Notification 

Flow  Control 

FUNCTIONS 

TRANSPORT  LAYER  (4) 

Message  Assembly  -  Disassembly 
Error  Detection  and  Recovery 
Address  Mapping  (Transport  to  Network) 
Multiplexing  of  Transport  to  Network  Connections 


Sequence  Control 


FUNCTIONS 


SESSION  LAYER  (5) 

o  Setup  of  Session  Protocols 

o  Data  Unit  Sequence  Numbering 

o  Interaction  Management 

o  Exception  Reporting 

FUNCTIONS 

PRESENTATION  LAYER  (6) 

o  Session  Establishment  Request 

o  Presentation  Image  Negotiation 

o  Data  Transformation  and  Formatting 
o  Special  Purpose  Transformations  (Encryption) 

o  Session  Termination  Requests 
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COMMUNICATIONS  OPERATION- 


FACTORY  INFORMATION 
MANAGEMENT 


EM  COMMUNICATIONS  OPERATION 


COMMUNICATIONS  OPERATION 


OEM  COMMUNICATIONS  OPERATION 


OEM  COMMUNICATIONS  OPERATION- 


STATUS  OF  GRAPHICS  AND  DATA  BASE  STANDARDS 


Standard 

ANSI 
Wkg . 
Docu¬ 
ment 

Dp ANSI 

ANSI 

ISO 

Work 

Item 

GKS 

X 

1/85 

VDM 

X 

5/85 

X 

PHIGS 

X 

2/85 

X 

VDI 

X 

NAPLPS 

X 

CORE 

IRDS 

X 

1/85 

X 

NDL 

X 

X 

RDL 

X 

1/85 

X 

DF 
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DpISO  DISO 

ISO 

Draft 

FIPS 

FIPS 
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6/85 
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STATUS  OF  VENDOR  IGES  IMPLEMENTATIONS 
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Demonstrated  Advertised  Sofware 

Inter  System  Translators  In-Work 

APPLICON  X 

AUTOTROL  X 

BAUSCH  &  LOMB  X 

BRUING  CAD  X 
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CALCOMP 
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CAMAX  SYSTEMS  x 
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CONTROL  DATA  X 
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INTERGRAPH 
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Tape 
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STATUS  OF  VENDOR  IGES  IMPLEMENTATIONS 


Demonstrated  Advertised  Sofware  Supplied 

Inter  System  Translators  In-Work  Tape 


LUNDY 

MARC  SOFTWARE 
MARTIN  MARIETTA 
MATRA  DATAVISION 
MCS  Inc. 

MDSI 

METAGRAPHICS 
OMNICAD 
PRIME  MEDUSA 
PRIME  PDGS 
SDRC 

SUMMAGRAPHICS 

SYSTEMHOUSE 

T  &  W  SYSTEMS 

TEKTRONICS 

UNIGRAPHICS 

VERSATEC 

WEBER  NC 
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REPORT  NO.  16 

GENCODE*/ SGML  STRENGTHS 
IN  THE  TEXT  PROCESSING  ENVIRONMENT 


PART 

I. 

Summary  Recommendations 

PART 

II. 

GenCodeVSGML  Strengths 

PART 

III. 

GenCode */SGML 

Standard  Development  Status 

William  W.  Tunnicliffe 
Vice-President,  Information  Technologies 
Graphic  Communications  Association 
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1. 

SPECIFIC  RECOMMENDATIONS 


1.  It  is  specifically  recommended  that  the  plan  and  proposal 
outlined  in  the  PRIORITY  ITEM  listing  and  in  the  following 
CALS  Project  Recommendations  be  implemented  as  expeditiously 
as  possible. 

2.  The  benefits  of  the  plan  include: 

a.  Convincing  demonstration  that  will  establish 
credibility  for  use  in  the  Logistics  Area. 

b.  Demonstration  materials  for  each  stage  of  the 

process  -  which  may  be  supplied  in 

"Demonstration  Kit"  form  for  widespread,  parallel 
use  — -  which  will  be  of  significant  service 

in  "selling"  this  application  approach  within  and 
outside  the  Department  of  Defense. 

c.  Conclusive  evidence  of  the  utility  of  a  combined 
IGES  /  GENCODE  approach. 

J.  The  tasks  included  above  will  show  the  results  of  Document 

Analysis  and  Document  Assembly  utilizing  the  highest  attained 
level  of  implementation  as  measured  against  the  latest  GenCodeVSGML 
Standard  (Working  Draft  9),  GCA  Standard  101-1983,  Change  No.  1. 

It  is  recommended  additionally,  that  a  new,  special  task  be 
established  to  provide  a  retrospective  analysis  of  a  project 
such  as  ATOS  in  order: 

a.  To  utilize  the  attained  results  as  a  platform 
and  vehicle  to  accelerate  the  implementation 
of  additional  GenCode*  Projects?  and 

b.  To  analyze  and  measure  the  attained  results 
against  the  latest  version  of  the  standard 

-  with  a  view  toward  definition  of  a 

practical,  workable  implementation  approach 
which  can  be  used  in  a  significant  number 

of  projects  in  parallel  within  all  applicable 
jurisdictions. 
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1. 

SPECIFIC  RECOMMENDATIONS  (Contd) 


4.  It  is  specifically  recommended  that  the  Program  Management 
approach  described  be  used.  This  approach  will  take 
advantage  of  the  accumulated  experience  of  that  group 
of  people  who  have  literally  devoted  years  to  the 
development  of  the  features  of  the  standard  and  who 
have  very  direct  experience  with  system  implementations. 

a.  The  Members  of  the  GCA  GenCode*  Committe 
are  listed  in  Report  No.  33,  "Standards 
Development  Structure  and  Participating 
Personnel . ” 

b.  The  extent  of  participation  in  the  ANSI  and 
ISO  Standards  Development  Process  is  given 
both  collectively  and  individually. 

c.  It  is  proposed  that  these  individuals  provide 

guidance  as  a  "Board  of  Overseers"  -  together 

with  individuals  from  the  Project  Sponsor 
organization  -  and  provide  contribution 

in  the  execution  of  the  required  tasks. 


5.  It  is  felt  that  the  following  items,  selected  from  the  over-all 
program/project  list  which  follows,  are  PRIORITY  ITEMS; 

a.  Document  Analysis 

(1)  Thorough,  addressing  a  widely  recognized  and 
understood  set  of  documents  —  for  example: 

(a)  A  Logistics  Document 

(b)  The  set  of  Military  Specifications  and 
Standards  called  out  for  as  major  project 

(2)  Providing  an  analysis  AND  an  associated 
tutorial  package  to  explain  the  approach 
taken  to  analysis. 

b.  Educational  £  Training  Materials 

(1)  GenCode "/SGML  Primer 

(2)  GenCode "/SGML  VIDEO  Tutorial 
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2. 

GENERAL  RECOMMENDATIONS  &  OBSERVATIONS 


There  are  several  general  guidelines  suggested  for  development  of 
an  over-all/  coordinated  program: 


1.  The  concept  and  status  of  the  standard  on  the  one  hand  and 
of  implementations  on  the  other  simply  MUST  be  understood. 

2.  it  must  be  understood  that,  while  the  standard  is  well 
along,  implementations  must  be  demonstrated,  implementations 
will  be  proprietary  (in  the  absence  of  any  other  factor), 
and  that  implementations  are  a  "mustl" 

3.  The  "IMPLEMENTATION"  is  what  allows  the  "AAP/STM  Author 

Guidelines  &  Keyboarding  Conventions"  -  or  the 

"TechDoc*  Author  Guidelines  &  Keyboarding  Conventions" 
to  take  workable  form. 

4.  The  area  of  focus  for  GenCode*  is  "Manuscript  Preparation 

&  Text  Interchange"  -  with  "System  and  Device  Independence" 

-  for  all  areas  of  Logistics  Documentation,  Technical 

Data,  and  Technical  Documentation,  leading  to  the 
ability  to  express  the  material  in  a  variety  of  output 
product  forms.  It  is  NOT  simply  to  "automate"  production. 

5.  One  important  exception  must  be  noted  for  clarity. 

If  one  reviews  the  "whole"  standard,  one  notes  that  there 
are  10  parts,  of  which  SGML  is  Part  Six.  It  must  be 
pointed  out  that  the  thrust  of  the  GenCode*/SGML  approach 
is  the  use  of  the  Text  Description  Language  defined  by  the 
the  SGML  Standard  and  is  restricted  to  that  area. 

The  GenCodeVSGML  approach  does  NOT  require,  nor  does  it 
propose,  the  use  of  the  Text  Processing  Language  being 
developed  under  other  parts  of  the  over-all  ISO  SC18  WG8  / 

ANSI  X3V1.8  standard. 
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CALS  Program  Recommendations 


A.  TEXT-PLUS  COMPONENTS 


GENCODE*/ SGML 


1.  Demonstration  Projects  Text  Only 

a.  Document  Analysis 

(1)  Technical  Publication 


(a) 

Specification 

Only 

(b) 

Standard 

Only 

(c) 

Technical  Manual 

Only 

(2) 

Logistics  Publication 

(a) 

LSA  /  LSAR 

Only 

Document 

Assembly 

(1) 

Technical  Publication 

(a) 

Specification 

Only 

(b) 

Standard 

Only 

(c) 

Technical  Manual 

Only 

(2) 

Logistics  Publication 

(a) 

LSA  /  LSAR 

Only 

c.  Document  Assembly 

(3)  Technical  Publication 

(4)  Technical  Publication 

(5)  Technical  Publication 


Text  Plus:. 


Supplied  Art 
IGES 

IGES  and  GKS 


d.  Document  Registration 


By  kind  of  document  structure 
For  all  document  cases  above. 


e.  Equipment  /  System  Projected  demonstration. 

(WYSIWYG  on  screen;  ) 

(SGML  codes  in  output.  ) 
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ida2. 914-3 


CALS  Program  Recommendations 

(Contd) 


(Contd ) 


A.  TEXT-PLOS  COMPONENTS 

2.  Certification  Projects 

a.  Retrospective  Analysis 

b.  Document  Assembly  Case 

c.  List  of  Certified  Implementations 

d.  Prior-To-Use  Application  Plan 

3.  Project  Reports 

a.  Progress  Reports 

b.  Project  Reports 


4.  Training  &  Training  Materials 

5.  Education  &  Educational  Materials 


Incorporated  in 

Program  Management  Reports 

Final  Reports  for  each 
Individual  Project 


f.  Demonstration-Case  Exhibit  Kits 
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a. 

GENCODE* 

Primer 

b. 

GENCODE* 

Tutorials 

Live,  plus  handouts 

r”: 

ri 

c. 

GENCODE* 

Tutorials 

Video  Cassette,  plus  handouts 

rl* 

d. 

GENCODE* 

Tutorials 

Audio  Cassettes,  plus  handouts 

e. 

Handbooit 

Standards  &  Procedures 

Logistics  Applications 

TechPub  Applications 

** 

-  •.'l 
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CALS  Program  Recommendations 


(Contd) 


LIAISON  WITH  ORGANIZATIONS  CONCERNED  WITH  IGES 

1.  Automated  Production  Technology  Division 
Center  for  Manufacturing  Engineering 
National  Bureau  of  Standards 


LIAISON  WITH  ORGANIZATIONS  CONCERNED  WITH  GENCODE*/ SGML 
1.  WEAPONS  SUPPORT  /  LOGISTICS 


DMSSO 

STANDARDS 


ISO  TC97/SC18/WG8 


(ASSOCIATION  &  COMMUNITY) 
CLPT 

COMPUTER  LANGUAGES  FOR  THE 
PROCESSING  OF  TEXT; 

SGML 

STANDARD  GENERALIZED 
MARKUP  LANGUAGE 
INCLUDED  AS  SUBGROUP 


ISO  TC97/SC18/WG1 
through  /WG5 

ANSI  X3V1 

X3V1.1 
thru  X3V1.5 


TEXT  &  OFFICE  SYSTEMS 


TEXT  &  OFFICE  SYSTEMS 


ANSI  X3V1.8 

X3V1.8.1 


X3V1.8.2 


Special  Note: 


LOGISTICS 


CLPT  TASK  GROUP 

TEXT  DESCRIPTION  LANGUAGE 

SUBTASK  GROUP 

SGML 

DOCUMENT  REGISTRATION  PROCEDUR: 
SUBTASK  GROUP 

X3J6  was  transferred  to  X3V1 
in  its  entirety  and  has  become 
Task  Group  8  within  X3V1. 

(ASSOCIATION  6  COMMUNITY) 


AIA 

Aerospace  Industries 
Assoc' n  of  America 


(ASSOCIATION  &  COMMUNITY) 


T  t 
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CALS  Program  Recommendations 


(Contd) 


C.  LIAISON  WITH  ORGANIZATIONS  CONCERNED  WITH  GENCODE*/ SGML  (Contd) 

6.  AAP  (ASSOCIATION  &  COMMUNITY) 

Association  of 

American  Publishers 

7.  GENCODE*  (ASSOCIATION  &  COMMUNITY) 

Graphic  Communications 

Association 

8.  SGML  USERS'  GROUP  (ASSOCIATION  &  COMMUNITY) 

Graphic  Communications 

Association 


D .  PROGRAM  MANAGEMENT 

1.  PROGRAM  &  PROJECT  DEFINITION 

2.  PROJECT/TASK-DIRECTION  MANAGEMENT 

3.  REPORT  PRODUCTION  —  PROGRESS  &  FINAL 

4.  CONTRACTS  FROM  CONTRACTING  ORGANIZATION 

5.  CONTRACTS  TO  SUPPLYING  INDIVIDUALS  &  ORGANIZATIONS 

6.  SCOPE/SCHEDULE/TERMS/ COST  MONITORING 

7.  PROGRAM  SUPPORT  —  ADMINISTRATION,  FINANCE,  ETC. 


E.  BASIC  PROGRAM  PHILOSOPHIES 

1.  DEPARTMENT  OF  DEFENSE  ADOPTION  OF 

GCA  STANDARD  101-1983  (10  AUG  1983) 

CHANGE  NO.  1  (15  JAN  1985) 

2.  CONCURRENT  PROJECTS  &  TASKS 

3.  PROJECTS  DIRECTLY  FEED 

IMPLEMENTATIONS 
OPERATIONS 
OPERATIONS  SUPPORT 

4.  KEY  PERSONNEL  AN  EXISTING  TEAM 

FROM  X3V1 .8.1 
FROM  X3V1 .8.2 

5.  ADDITIONAL  PERSONNEL 

BY  TASK 
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PART  II.  GENCODE*/ SGML  STRENGTHS 


1.  Purpose. 

Standardization  of  the  computer/systera-sensitive  text  and 
data  format  for  Computer-Aided  Documentation  and  Publications 
systems  will  allow  text  and  data  to  be  exchanged  effectively. 

The  text  and  data  involved  covers  the  entire  "need"  spectrum: 
over-all  technical  documentation  (business,  logistics,  scientific,  etc.), 
specific-system  manuals  of  all  kinds  (operations,  maintenance,  theory 
of  operations,  training,  etc.),  drawing  nomenclature  (title  block, 
bill  of  materials,  and  annotations  —  i.e.,  all  non-geometric  data. 

The  PRINCIPAL  STRENGTH  fii  GenCodeVSGML  is  tfl  address  &  multiplicity 
Ql  output,  ataxage.  sod  telecommunications  forms  from  ihs  SAME  SOURCE 
PILE,  without  haying  hn  change  ihfi  tags. 


2.  Background 

The  GenCode*  concept  and  methodology  deals  with  the  creation, 
preparation,  processing,  and  presentation  of  intellectual  content  which 
hasbeencoded  (or  "tagged")  to  identify  the  editorial  elements  and 
the  editorial  structure  of  the  content.  In  the  various  proc¬ 
essing  (or  manufacturing)  steps  in  the  path  from  the  author's  mind  to 
the  information  consumer's  mind  (the  presentation  can  be  in  either 
printed  or  electronic  form),  the  editorial  tags  identify  the  points 
in  the  lineal  text  stream  at  which  steps  in  the  editorial  structure 
are  encountered  (see  Figure  1)  or  at  which  the  editorial -element  kind 
changes;  at  which  figures,  illustrations,  line  art,  footnotes,  or  other 
"detached"  materials  (i.e.,  presented  "outside"  of  the  lineal  text  stream) 
are  encountered.  (See  Figures  2  and  3.)  These  tag  points  identify  the 
locations  at  which  the  nature  of  the  output  presentation  device  and 
process  must  change  (i.e.,  output  is  machine-  or  system-particular 
at  output  time).  Examples  include:  line-printer,  matrix  printer,  laser 
printer,  facsimile,  photocomposition,  VDT  (video-display  terminal) , audio, 
etc.  It  is  important  to  note  that  the  source  file  remains  the  same  (i.e., 
it  does  NOT  have  to  be  recoded)  for  any  variation  of  visual  display 
output.  GenCodeVSGML  files  are  coded  in  the  "language  of  interchange" 

—  the  neutral  format.  Each  display  output  device  requires  its  own 
pre-processor  to  accept  this  language  of  interchange  and  convert  it 
to  the  required  machine-specific  codes  for  numerical  control  of 
that  particular  output  device.  (See  Figures  4  and  5.) 


The  basic  methodology  is  one  of  unique,  unambiguous  ident¬ 
ification  of  each  editorial  element.  GCA  Standard  101-1983,  The 
Document  Markup  Metalanguage  (SGML  —  The  Standard  Generalized  Markup 
Language)  provides  a  syntax  and  semantics  which  regiment  the  coding. 

This  allows  operational  simplicity  and,  equally  if  not  more  importantly, 
provides  the  opportunity  for  a  processing  activity  (or  processing  supplier 


to  create  a  single  SGML  pre-processor.  The  one  pre-processor 
will  accommodate  all  jobs  so  coded,  rather  than  necessitating  a 
separate  pre-processor  for  each  particular  job.  An  important 
feature  of  the  SGML  approach  is,  for  example,  the  ability  to  identify 

a  paragraph  -  at  any  level  within  the  editorial  hierarchy  - 

by  the  tag  "<P>."  The  SGML  parser  "keeps  track"  of  the  level  of 
the  editorial  structure  at  which  that  particular  paragraph  starts  and, 
internally,  issues  a  composite  code  which  identifies  the  level  and  the 
fact  that  a  paragraph  is  beginning.  The  "composite”  code  is  called 
the  "Fully  Qualified  Generic  Identifier."  (See  Figure  6.) 

The  thrust  of  this  straight-forward  example  illustrates 
the  power  of  the  GenCodeVSGML  approach.  The  coding  is  at  the 

highest-possible  level  of  abstraction  -  i.e.,  the  codes  (tags) 

and  the  content  are  both  within  the  same  character  set;  there  are 

no  "special"  codes;  there  are  no  "function"  codes.  Thus, 

the  composite  stream  is  in  "neutral"  format,  a  form  transparent 

to  the  mode  of  communication.  The  coding  is  "human-readable" 

as  well  as  machine-readable.  The  whole  process  is  "human-intelligible" 

-  almost  simplistic.  The  process  constitutes  a  highly  advantageous 

division  of  functions:  human  authors/editors/operators  make  the 
intellectual  judgments;  the  SGML  pre-processor  computer  software 
deals  with  the  complexities  and  myriads  of  detail  in  the  full  processing. 

Figure  7  illustrates  yet  another  dimension  of  "user  friendliness" 

—  what  might  be  termed  "applications-level"  standards,  or  "author 
guidelines,"  to  establish  the  editorial  identifier  tags  to  suit  the 
preferences  (and/or  jargon)  of  any  particular  user  community.  Figure  7 
shows  the  AAP/STM  (Association  of  American  Publishers  /  Scientific, 
Technical,  and  Medical  Publishers)  —  the  book  publishing  community  — 
and  Technical  Documentation,  the  Logistics,  Technical  Data,  Technical 
Manuals,  etc.  community  as  two  representative  cases.  Note  also  that 
Figure  7  symbolizes  the  converging  technologies  and  the  converging 
applications  of  SGML  and  word  processors.  Recognition  of  this 
convergence  has  led  to  the  assimilation  by  ANSI  X3V1  of  ANSI  X3J6 

—  to  form  a  combined  committee  addressing  the  needs  of  both 
Office  and  Publishing  Systems. 

Figure  8  symbolizes  an  important  commercial  factor.  The 
GenCodeVSGML  emphasis  is  on  neutral  format  to  accommodate 

manuscript  preparation  and  text  (all  categories  -  facsimile, 

graphics,  audio,  etc.)  interchange.  On  either  side  of  the 
"neutral  zone  of  interchange,"  there  remains  unrestricted 
room  to  develop  and  demonstrate  inventive  expression.  The 
techniques  so  developed  fall  clearly  within  the  area  of 
proprietary  rights,  and,  accordingly,  provide  the  desired 
commercial  incentives. 
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idausn.2-6 
3.  Implementation 

Implementation  o£  a  system  meeting  the  requirements  of  GCA  Standarc 
101-1983,  Change  No.  1,  will  require  software  implementation  of  a 
pre-processor.  Examples  of  different  approaches  to  implementation 

-  based  upon  systems  approaching  compliance  with  the  provisions 

of  the  Standards: 


(1)  Xh£  Previous  Standard 

GCA  Standard  101-1983  Exhibit  1 


(2)  current  standard 

GCA  Standard  101-1983,  Change  No.  1  Exhibit  2 

include: 

(3)  Purchase-o£-Servicea  Contract 

Computerized  Electronic  Photcomposition  Exhibit  3 
and  related  services 
Internal  Revenue  Service 

(4)  System  Implementation  Contract 

ATOS  -  Automated  Technical  Order  System  Exhibit  4 
(J.S.  Air  Force 

Related  background  includes: 

(5)  System  Implementation  Support  Exhibit  5 

Documentation 

Document  Type  Definitions  &  Examples 
ATOS,  U.S.  Air  Force 


(6)  Basic  Generic  Coding  CoaCfiptS 


Exhibit  6 
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LIST  OP  EXHIBITS 


No.  Title 


1  GCA  Standard  101-1983,  Document  Markup  Metalanguage, 

Adopted  by  Department  of  Defense,  10  August  1983 

GenCode*  and  The  Standard  Generalized  Markup  Language  (SGML) 

Graphic  Communications  Association 

Arlington,  VA  22209 

2  GCA  Standard  101-1983,  Change  No.  1 

•  Generic  Document  Representation  Specification  (SGML) 

Adopted  by  Department  of  Defense,  15  January  1985 
Graphic  Communications  Association 
Arlington,  VA  22209 

3  Computerized  Electronic  Photocomposition  and  related  services 
Solicitation,  Offer  and  Award  IRS-P-84-2 

Department  of  Treasury  —  Internal  Revenue  Service 
Washington,  D.C.  20224 

4  Manuals,  Technical:  General  Style  and  Format  Requirements 
Military  Specification  MIL-M-38784A,  1  January  1975 

5  Text  Standard  Generalized  Markup  Language, 

Automated  Technical  Order  System  (ATOS) 

Technical  Report  No.  P42650-84-C3851 
Code  OO-ALC/MMED,  Hill  APB,  Utah  84056 

6  GenCode*  Techniques  For  Authors 
Proceedings  of  the  Fifth  Annual  Meeting  of 
The  Society  For  Scholarly  Publishing 

May  15-20,  1983,  Philadelphia,  PA,  pgs  90-101 
The  Society  For  Scholarly  Publishing 
Washington,  DC  20009 
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4.  Definitions.  For  the  specific  purpose  of  the  CALS  Study, 

.t  is  important  to  note  that  the  coverage  of  GenCodeVSGML 
includes  all  of  the  NON-geometric  data  and  provides  the 
"identification-point”  tags  which  allow  proper  interlacing  of 
non-geometric  and  geometric  data.  Included  are: 

a.  Product  Definition  Data.  Data  required  to  describe  and  commun¬ 
icate  the  characteristics  of  physical  objects  as  manufactured  products. 

b.  Technical  Data.  The  total  compilation  of  all  engineering 
documentation  necessary  to  describe  the  non-geometric  product  definition 
data  of  engineering  drawings  in  accordance  with  DoD-MIL-lOOC,  DoD-D-lOOOB, 
and  MIL-D-5840 .  This  covers  title  block,  bill  of  materials,  and  annotations. 

d.  Technical  Documentation.  The  total  compilation  of  all 
technical  documentation  necessary  to  support  the  manufactured  products. 

E.g.,  this  documentation  includes:  business,  logistics,  and  scientific 
documentation  plus  system/ equipment-spec if ic  manuals  of  all  kinds: 
operations,  maintenance,  theory  of  operations,  and  training. 


5.  Availability 

Copies  of  GCA  Standard  101-1983,  Change  No.  1,  can  be  obtained  from 
the  Graphic  Communications  Association,  1730  North  Lynn  Street,  Suite  604, 
Arlington,  VA  22209.  The  current  price  is  $XX.xx. 


& 
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PART  III.  GENCODEVSGML  STANDARD  DEVELOPMENT  STATUS 
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1.  Derivation 

The  "Generic  Document  Representation  Specification  (SGML) , "  GCA 
Standard  101-1983,  Change  No.  1,  to  be  adopted  by  the  Department  of  Defense, 
Defense  circa  IS  January  1985,  was  developed  by  the  Graphic  Communications 
Association  through  the  work  of  its  members,  and  other  interested  parties, 
by  the  consensus  method  within  the  duly  constituted  standards  development 
process  defined  and  maintained  by  the  two  cognizant  standards  organ- 
izationsthe  American  National  Standards  Institute  (ANSI)  and  the 
International  Organisation  for  Standardisation  (ISO).  The  basic  version  was 
coordinated  for  adoption  by  the  Department  of  Defense  through  the  Director, 
Department  of  Defense  Computer  Standards  Office,  Headquarters,  U.S.  Air  Fore 
and  the  Defense  Materiel  Specifications  and  Standards  Office,  Office  of 
The  Undersecretary  of  Defense  for  Research  and  Engineering.  The  GCA  request 
for  processing  the  adoption  of  Change  No.  1  will  be  submitted  in 
similar  fashion. 


2.  Promulgation 

GCA  promulgated  the  basic  version,  and  will  promulgate  the 
Change  No.  1  version,  of  the  standard  to  provide  the  domestic 
and  international  documentation,  printing,  and  publishing  communities 
with  access  to  this  standard  for  trial-use  during  the  period  of 
completion  of  the  process  of  formal  review  and  adoption  of  it  by  the 
International  Organisation  for  Standardisation.  Adoption  of  the  basic 
version  of  the  standard  on  10  August  1983  by  the  Department  of  Defense 
has  served  to  make  the  standard  available  within  DoD,  the  government 
at  large,  and  commerce  and  industry  in  North  America,  Europe,  and 
the  United  Kingdom.  Adoption  of  Change  No.  1  is  expected  to  have 
an  even  greater  beneficial  effect. 
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3.  Nomenclature 

GCA  Standard  101-1983,  Change  No.  1,  is  the  literal  text  of 
the  document  identified  as  the: 

Ninth  Working  Draft, 

International  Standard 
ISO  TC97/SC18/WG8  N40 
1984  Nov  08 

where: 

Technical  Committee  97  »  Information  Processing 

Sub-Committee  18  *  Text  Preparation  and  Interchange 

Working  Group  8  *  Processing  and  Markup  Languages 

and  the  document  is  formally  entitled: 

"Information  Processing  Systems  - 

Text  Preparation  and  Interchange  - 

Processing  and  Markup  Languages  - 

Part  Six:  Generic  Document  Representation  Specification  (SGML)” 


"SGML”  is  an  acronym  referring  to  "Standard  Generalized  Markup 
Language,”  a  subtitle  phrase  previously  related  to  Part  Six. 
Part  Six  is  commonly  referred  to  as  "SGML”  or  "GenCode*." 
to  as  "SGML"  or  "GenCode,"  independent  of  any  assigned 
formal  title. 


4.  Status  of  Ballots 

a.  DP  (Draft  Proposed)  Registration 

The  ballot  for  registration  as  a  DP  (Draft  Proposed)  was 
issued  by  the  ISO  TC97/SC18  Secretariat  in  November  84  with  a  return 
date  of  21  Dec  84.  The  Working  Group  8  standard  is  a  "multi-part” 

standard;  the  ballot  requires  voting  by  individual  part  -  i.e., 

there  is  an  individual  ballot  for  Part  Six:  SGML. 

b.  DPIS  (Draft  Proposed  International  Standard) 

If  approved  and  assigned  a  DP  Number  (Draft  Proposed), 
a  three-month  ballot  will  be  issued  by  the  ISO  TC97/SC18  Secretariat 
for  approval  of  the  substantive  content.  The  return  date  will  be  planned 
to  occur  before  the  TC97/SC18  Plenary  scheduled  for  Washington,  D.C. 
during  the  week  of  22  April  1985.  This  ballot  will  also  require  voting  by 
individual  part.  Upon  approval,  the  then-current  draft  will  be  issued  as 
a  dpis  (Draft  Proposed  International  Standard). 
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4.  Status  of  Ballots  (Contd) 

c.  DIS  (Draft  International  Standard) 

Upon  incorporation  of  any  further  refinements,  the  DPIS 
will  be  submitted  for  approval  as  a  DIS  (Draft  International  Standard). 

d.  IS  (International  Standard) 

Upon  completion  of  further  formal  processing  the  document  will 
become  an  International  Standard. 

e.  ANSI  Standard 

At  that  point,  it  is  planned  that  the  document  become  an 
ANSI  (American  National  Standards  Institute)  Standard  by  adoption 
in  toto. 

It  should  be  noted  in  passing  that  it  is  the  declared  policy 
of  ANSI  Committee  X3V1,  now  responsible  for  the  SGML  Standard,  that 
every  effort  should  be  made  to  obtain  the  ISO  version  of  the  SGML 
Standard  first,  that  an  independent  ANSI  version  should  be  sought 
only  after  all  efforts  to  obtain  the  ISO  version  have  failed. 

f.  Relationship  to  Word  Processing 

The  word-processing  world  is  currently  represented  by  activ¬ 
ities  of  the  U.S.  Navy  and  ISO  TC97/SC18  Working  Groups  2,  3,  and  4. 
"Document  Interchange  Format  (Interim),"  a  Naval  Data  Automation  Technical 

Standard,  NAVDAC  PUB  17.11  — -  commonly  referred  to  as  "DIF"  

"provides  interim  guidance  pending  formal  actions  by  the  National  Bureau 
of  Standards  regarding  the  encoding  of  information  for  exchange  among 
text  processors."  The  ISO  documents,  registered  as  DP  8613/2,  DP  8613/3, 
and  DP  8613/4  (Draft  Proposed),  are  formally  entitled,  "Information  Proces 

ing  -  Text  Preparation  and  Interchange  -  Text  Structures  - 

Part  2:  Office  Document  Architecture;  Part  3:  Document  Profile, 

and  Part  4:  Office  Document  Interchange  Formats"  -  commonly 

referred  to  as  "ODA"  and  "ODIF." 

In  cooperatively  related  work  of  Working  Groups  2,3,4,  and  8 
in  an  Ad  Hoc  Meeting  in  Toronto  19-21  September,  in  the  formal  WG3  meetinc 
in  Ottawa  24-28  September,  and  in  the  formal  WG8  meeting  in  Rotterdam 
22-26  October,  the  specification  text  for  ODA  and  ODIF  has  been  modified 

to  incorporate  "SGML  modules"  -  i.e.,  operationally,  ODA  can  be  speci: 

by  SGML.  Technical  agreements  were  originally  drafted  in  Toronto  by 
representatives  of  Working  Groups  3  and  8  of  ISO  TC97/SC18  and  were  refir 
to  the  satisfaction  of  both  groups  in  Rotterdam  as  of  26  Oct  84. 
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4.  Status  of  Ballets  (Contd) 
g.  Most-Rsesnt  Bxtansion 

GCA  Standard  101-1983,  Change  No.  1  (i.e.,  the  Ninth  Working 
Draft  resulting  from  international  committee  work  during  the  Rotterdam 
meeting  of  WG8,  22-26  Oct  84)  represents  both  a  refinement  and  an 
extension  of  the  basic  version,  GCA  Standard  101-1983.  Extensions  and 
enhancemenrs  have  been  incorporated  in  the  Standard  to  establish  a  com¬ 
patible  "bridge"  to  and  from  the  word-processing  world.  The  modificati 
allow,  when  desired,  increased  direct  relationships  between  form  and 
content,  between  word  processing  and  coding  according  to  data  element 
and  editorial  structure  categories. 
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REPORT  NO.  17A 


STANDARDS  FOR  INDUSTRIAL  AUTOMATION 


When  one  thinks  of  standards  for  manufacturing,  first 
thoughts  turn  toward  those  for  weights  and  measures,  for 
these  are  certainly  the  oldest  and  are  probably  the  most 
frequently  encountered  on  the  shop  floor  when  objectives 
of  part  interchangeability  or  system  performance  demand 
tight  manufacturing  tolerances.  This  view  of  industrial 
automation  involves  many  standards  that  are  mandatory  and 
are  controlled  by  law.  Application  of  those  standards 
often  occurs  through  artifacts  or  gauges  that  have  a  calibra¬ 
tion  traceable  to  national  standards  laboratories.  While 
these  standards  have  application  to  manufacturing,  they 
are  not  central  to  problems  of  CAD/CAM  integration.  There 
are  other  standards  that  are  applied  with  the  force  of 
law.  These,  of  course,  include  those  dealing  with  safety 
and  health  such  as  pollution  control,  flammability,  shock 
and  building  codes.  However,  mandatory  standards  will 
not  be  addressed  here  as  they  are  not  unique  to  the  problems 
of  industrial  automation.  Rather,  our  attention  is  drawn 
to  the  larger  number  of  voluntary  standards  developed  by 
concensus  agreement  to  define  products,  practices,  materials 
and  interfaces. 

One  large  class  of  voluntary  standards  addresses  the 
physical  components  which  together  form  the  industrial 
equipment  itself.  Many  standards  exist  here  for  the  electrical, 
mechanical,  metallurgical,  and  environmental  aspects  of 
equipment.  Examples  would  include  screw  threads,  roller 
chain,  and  gear  teeth.  These  standards,  like  those  for 
length  and  measure,  are  peripheral  to  the  problems  of  inter¬ 
facing  computer-based  manufacturing  systems. 
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A  wealth  of  manufacturing  process  standards  exist 
within  many  industrial  facilities  to  define  drawing  specifica¬ 
tions,  part  numbering  conventions,  group  technology  codes, 
purchase  orders,  and  such.  While  these  are  useful  standards, 
they  are  not  unique  to  industrial  automation  and  are  equally 
applicable  to  conventional  manufacturing. 

Interfacing  equipment  on  the  shop  floor  is  often  quite 
difficult  because  of  the  lack  of  standards  for  electrical 
voltage  and  impedance  levels  of  inputs  and  outputs  used 
for  interlock  control  or  for  the  mechanical  interfaces 
on  machine  tools  and  industrial  robots.  One  example  concerns 
robot  and  effectors.  Mounting  surfaces  and  bolt  hold  patterns 
have  no  standards  at  present  forcing  a  range  of  grippers 
to  be  procured  or  fabricated  for  each  robot  on  the  floor. 

An  exception  ex’sts,  however,  in  the  ANSI  Standard  for 
tool  holders  on  NC  machining  centers. 

Much  of  the  new  automation  equipment  being  installed 
owes  its  success  to  embedded  computer  technology  used  to 
optimize  system  performance.  Additionally,  stand-alone 
computers  are  assisting  at  every  level  of  manufacturing 
planning  and  control.  It  is  obvious  that  a  wealth  of  standards 
exist  concerning  computer  technology.  Some  of  these  are 
pertinent  to  the  application  of  computers  in  industrial 
automation.  The  key  word  here  is  "application"  for  there 
is  only  a  subset  of  computer  standards  which  are  germane 
to  CAD/CAM  and  factory  automation.  So  as  not  to  cloud 
the  main  discussions,  peripheral  computer  standards  will 
not  be  highlighted. 

Computer  standards  which  are  thought  to  be  useful 
for  applications  in  industrial  automation  include  those 
necessary  to  meet  objectives  of  portability  of  software, 
integration  of  software  modules,  exchangeability  of  manu- 
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facturing  data,  and  distributed  data  processing.  Software 
portability  is  addressed  by  standards  for  computer  languages 
and  program  documentation.  Also  of  interest  here  are  the 
evolving  standards  to  enable  applications  programming  to 
be  independent  of  the  exact  terminal  devices  being  used. 
Computer  standards  on  data  base  management  systems  are 
a  necessary  part  of  an  approach  to  integration  of  software 
modules. 

Exchangeability  of  manufacturing  data  is  an  important 
issue  and  is  assisted  by  a  range  of  standards  defining 
data  base  exchange  formats,  computer  media  and  languages 
for  manufacturing  process  descriptions  such  as  are  found 
with  NC  machining,  robotics  and  coordinate  inspection  machines. 
The  last  area  of  computer  standards  applicable  to  industrial 
automation  focuses  upon  distributed  processing.  With  the 
variety  of  computer-based  equioment  -  micros  to  mainframes, 
standalone,  and  embedded  -  intercommunications  between 
devices  becomes  an  important  issue.  A  large  number  of 
standards  address  the  telecommunications  problem,  and  much 
recent  work  is  directed  at  local  area  networking. 

This  rationale  concludes  that  the  primary  interface 
standards  needed  by  users  involved  in  the  design  and  imple¬ 
mentation  of  industrial  automation  systems  have  to  do  with 
the  application  of  computers  to  the  processes  of  design, 
engineering,  manufacturing,  planning,  and  production,  and 
with  the  mechanical  and  electrical  interfaces  of  the  industrial 
equipment  on  the  shop  floor.  These  criteria  help  to  limit 
the  consideration  of  interface  standards  to  a  reasonable 
number  that  focus  attention  to  the  underlying  technical 
problems  that  are  encountered  when  building  integrated 
manufacturing  systems  in  a  multi-vendor  environment. 
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STANDARDS  SUMMARY  SHEET 


Committee  Title: 


Industrial  Automation  Systems 


Committee  Number: 


ISO  TC  184 


Chairman: 

M.  Dureau,  CIT  Alcatel,  France 
Sponsoring  Organization: 


Scope: 


International  Organization  for  Standardization  (ISO),  Geneva 


Standardization  in  the  field  of  Industrial  Automation  systems  encompassing  the 
application  of  multiple  technologies,  i.e.,  information  systems,  machines  and 
equipment,  and  telecommunications. 


Areas  of  Work: 


Numerical  control  of  machines 
Industrial  Robots 
Performance  Specifications 
Product  Data  Exchange 
Programming  Languages 


Subcommittees: 

SCI  Numerical  Control  of  Machines 
SC2  Industrial  Robots 

SC3  Non  Device  Specific  Application  Languages 
SC4  External  Representation  of  Product  Definition  Data 
SC 5  Requirements  for  Systems  Integration 
WG1  Communication  and  Interconnections 

Stanaards  Puoushed:  Various  publications  in  APT  and  Numerical  Control 

Drafts  In  Work:  Industrial  Robots  -  Definition  Classification  and  Graphic  Representation 
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STANDARDS  SUMMARY  SHEET 


Committee  Title: 

Initial  Graphics  Exchange  Specification 

Committee  Number: 

None 

Chairman: 

Bradford  Smith  National  Bureau  of  Standards 
Sponsoring  Organization: 

National  Bureau  of  Standards 

Scope: 

Product  data  representation  in  computer  readable  format  for  exchange  and  archiving 
in  the  area  of  computer  aided  design,  engineering,  manufacture  and  inspection. 


Areas  of  Work: 

Mechanical  Design 

Electrical  Printed  Wiring  Design 

Manufacturing 

Finite  Element  Mesh  Definition 


Subcommittees: 

Extensions  and  Repairs 
Test,  Evaluate  and  Support 

Standards  Published: 

IGES  Version  1.0 
ANSI  Y14.26M 

Drafts  in  Work:  Version  2.0 

IGES  Version  2.5 
Solids  Strawman 


STANDARDS  SUMMARY  SHEET 


Committee  Title* 

Numerical  Control  Systems  and  Equipment 

Committee  Number: 

IE-31 

Chairman: 

A1  Bacheier  Westinghouse,  Pittsburgh,  PA. 

Sponsoring  Organization: 

Electronic  Industries  Association 

Scope:  standardization  of  interlaces  with  the  electronic  controllers  for  numerical  control  of 
industrial  machine  tools  and  for  industrial  robots. 


Areas  of  Work: 

Communications  Protocols 
Operator  Interface 
Control  Data  Formats 
Machine  -  Controller  Interface 
Controller  Construction  Standards 


Subcommittees: 

Standards  Published: 


Drafts  in  Work: 


RS  4 94  Binary  CL  Exchange  Input  Format  for  NC  Machines 
RS  4S4  Interface  Characteristics  and  Line  Control  Protocol 


STANDARDS  SUMMARY  SHEET 


Committee  Titles 

Robotic  Systems 


Committee  Number: 

ASTM  F-2S 


Chairman: 

Gary  Sitzman,  Ford  Motor  Co.,  Dearborn 


Sponsoring  Organization: 

American  Society  for  Testing  and  Materials  (ASTM) 


Scope: 

The  development  of  standard  terminology,  test  methods,  practices, 
classifications,  and  guides  for  robotic  systems.  The  committee  shall  coordinate 
this  work  with  other  ASTM  technical  committees  and  organizations  having 
mutual  interest. 


Areas  of  Work: 

Terminology 
Performance  Criteria 
Application  Areas 
Robot  Safety 


Subcommittees: 

F28.01  Terminology  F28.03  System  Characterization 

F28.02  Performance  Criteria  F28.04  Liaison 

Standards  Published: 

None 


Drafts  in  Work: 

Payload  Rating  Dynamics  Test  Method 
Static  Repeatability  Definition 
Glossary  of  Terms 
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STANDARDS  SUMMARY  SHEET 


Committee  Title: 


Robotic  Terminology 


Committee  Number: 


ASTM  F28.1 


Chairman: 


Kenneth  Knott,  Pennsylvania  State  University 


Sponsoring  Organization: 


American  Society  for  Testing  and  Materials 


Scope: 


Under  Revision 


Areas  of  Work: 


Glossary  of  Robotic  Terms 


Subcommittees: 


Standards  Published: 


Drafts  in  Work: 


Glossary 
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STANDARDS  SUMMARY  SHEET 


Committee  Title: 

Robot  Performance  Criteria 

Committee  Number: 

ASTM  F2S.02 

Chairman: 

John  Reidy,  Battelle  Columbus  Labs 
Sponsoring  Organization: 

American  Society  for  Testing  and  Materials 

Scope: 

The  development  of  test  methods  necessary  to  evaluate  the  performance  of  robotic 
systems  and  components. 


Areas  of  Work: 

Performance  Test  criteria 
Performance  Terminology 


Subcommittees: 

None 

Standards  Published: 

None 

Drafts  in  Worlc 

Payload  Rating  Dynamics  Test  Method 
Static  Repeatability  Definition 
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STANDARDS  SUMMARY  SHEET 


Committee  Title 

Robotic  System  Categorization 

Committee  N  urn  ben 

ASTM  F28.03 


Chairman: 

Brian  Ford 

Sponsoring  Organization 


Ford  Industries,  Mahopac,  N.Y. 


American  Society  for  Testing  and  Materials 


Scope 

To  define  machine  characteristics  required  to  form  an  application  system 
configuration  performance. 


i 

Areas  of  Work: 

■ 


Subcommittees 


None 


Standards  Published: 


None 


Drafts  in  Work: 
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STANDARDS  SUMMARY  SHEET 


Committee  Title* 

R1A  Standards  Committee 
Committee  Number: 


Chairman: 

Dr.  Samuel  Korin  IBM  Manufacturing  Technology  Institute 
Sponsoring  Organization 

Robotics  Institute  of  America 


Scope: 

Standards  and  guidelines  for  construction  installation,  maintenance,  and  operation  of 
industrial  robots 


Areas  of  Work: 

Tooling  interface 
Mechanical  Systems 
Construction 
Programming  Languages 


Safety 

Sensory  Interface 

Pe.iormance 

Terminology 


Subcommittees: 

Safety 


Standards  Published: 

None 


Drafts  in  Work: 
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INTERNATIONAL  &  NATIONAL  —  ISO  &  ANSI 
STANDARDS  FOR  INFORMATION  PROCESSINGt 

William  W.  Tunnicliffe 
Graphic  Communications  Association 


Table  of  Contents 


A.  STRUCTURAL  ARRANGEMENTS 

1.  ISO  INTERNATIONAL  ORGANIZATION  FOR 
STANDARDIZATION 


a.  TC  97 

Information  Processing  Systems 

(1) 

SC  18 

Text  and  Office  Systems 

(a) 

WG8 

Text  Processing  Languages 

(2) 

SC21 

Information  Retrieval,  Transfer 
A  Management  for  Open  Systems 
Interconnection 

(b) 

WG5.2 

Computer  Graphics 

b.  TC  184 

Industrial  Automation  Systems 

(1) 

SCxx 

Initial  Graphic  Exchange 
Specification  (IGES) 

2.  ANSI  AMERICAN  NATIONAL  STANDARDS  INSTITUTE 


X3 

Information  Processing  Systems 

(1) 

X3V1 

Text  A  Office  Systems 

(a) 

X3V1.8 

Computer  Languages  for  the 
Processing  of  Text  Task 
Group 

(i) 

X3V1.8. 1 

Text  Description  Language 
Subtask  Group 

(ii) 

X3V1.8.2 

Document  Registration 
Subtask  Group 

t  This  is  a  partial  report.  For  more  information  contact 
the  Institute  for  Defense  Analyses. 
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REPORT  NO.  17B 

INTERNATIONAL  A  NATIONAL  --  ISO  &  ANSI 
STANDARDS  FOR  INFORMATION  PROCESSING 


Table  of  Contents  -  Continued 


B.  GCA  GBNCODE*  COMMITTEE  MEMBER  PARTICIPATION  IN 
ISO  A  ANSI  STANDARDS  DEVELOPMENT  ACTIVITIES 

1.  Summary  Listing  of  GenCode*  Committee  Members 

2.  Listing  of  Participation  by  Individual  Member 

3.  Listing  of  Participation  in  ISO  Committees 

4.  Listing  of  Participation  in  ANSI  Committees 


C.  FULL-MEMBERSHIP  DIRECTORIES  In  Order  Of: 


ISO  ANSI 

Convenor/Chairraan  Convenor  Chairman 

Vice-Chairman  -  X 

Secretary  -  X 

International  Representative  -  X 

Vocabulary  Representative  -  X 

Voting  Members  and  Alternates  X  35/9  X  18/9 

Members  in  Jeopardy  -  X  0 

Conditional  Members  -  X  2 

Observers  -  X  2 

Liaison  Representatives  X  9  X  10 

Consultants  X  10  X  10 

Probable  New  Attendees 

at  Next  Meeting  -  X  4 

Total  54/9  46/9 
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STANDARDS  FOR  INFORMATION  PROCESSING 


Table  of  Contents  -  Continued 


A. 

ISO  FULL 

SC  18  WG8 

12 

DIRECTORY: 

Consolidated  Telephone 

Directory 

1 

Total 

13 

B. 

ANSI  FULL 

TG  X3V1.8 

11 

DIRECTORY: 

STG  X3V1.8.1 

6 

STG  X3V1.8.2 

5 

Consolidated  Telephone 

Directory 

1 

Total 

23 

Notes  For  information  about  the  complete  report  contact 
IDA  (703)  845-2267. 


REPORT  MO.  18 

SUPPORT ABILITY  IMPLEMENTATION 
IN  THE  ACQUISITION  PROCESS 


Summary 

o  The  design  of  weapon  systems  occurs  in  a  tightly  compressed 
schedule  environment  in  which  the  supportability  influence 
must  be  exerted.  The  use  of  computers  will  enhance  this 
process  by  integrating  various  design  and  supportabililty 
functions. 

o  A  variety  of  data  bases  exists  which  serve  diverse 

functions.  It  is  necessary  to  extract  specific  data 
elements  for  use  by  various  disciplines  from  product  concept 
formulation  to  customer  feed-back. 

o  Many  models  exist  today  which  are  used  as  peripheral  tools 
to  assist  the  designer  and  supportability  engineer.  These 
models  impact  various  phases  of  the  acquisition  cycle  and  it 
is  necessary  to  ascertain  if  the  algorithms  in  these  models 
can  be  integrated  into  a  large  scale  model  with  milti- 
purpose  capability. 

o  Logistics  requirements  can  be  extracted  from  the  CAD/CAE 
that  affect  the  generation  of  LSA  sheets  and  cards. 
Furthermore,  the  design  of  support  equipment  and  training 
devices  can  naturally  follow  from  the  air  vehicle  (or  other 
system)  design  information. 

o  The  design  algorithms  must  be  specifically  tailored  to 
address  the  intended  use  of  the  system,  its  operational 
environment  and  integration  with  lessons  learned  and 
statistical  data  feedback. 

See  the  attached  visual  presentation  material  for  details. 

Bob  McCall 

Lockheed  Aircraft  Co. 


'Lockheed-  California  Company 


"^[Lockheed-  California  Company 


m 


S  Specification  Language  ►  Goals  and  Thresholds 

►  Makes  S  the  Designer’s  Job 


■o>Lin«ai«tiLaoj 

Qp*aiaittL£M~'(nL  • 

4i‘oa«a>3  u  n  u.  n  v 

it  9)  it  V  £  £  -*  i 

u«a3HUOf«  c 

qo  44  ov  i£  ii  n  l 

m  a  0  L  >  44  £  o  « 

Man  •  n  *•  «*  u 

n  3  m  at  m  ai  c  uc 
«  «  a  g  «  >  so 

at  >  »  l  »  nr  c  **  u 

4J  at  n  +»  *»  S  o  n 

m  C  it  m  C  33  MM 
III  «f  M>I3M  . 

XU  OttMlMltlttOI 
OCU  TImXUSO 


;  44  33  M  in 
0 


£  m  m  w  c 


c  n  a  n 


u  m  4i  a>  oi  l'Om  on 
ai  n  m  m  r  oi  ai  •a  l 

cit«3«4ic^ttai 

m  n  oi  in  oi  oi  3  l  is  n 

I OfllOCOMMOt 

00  ML  O  U  L  C  0 


ffi  in  an  3  C4141  «  It 
Rmoioi  nc-n  c 
m  £  >  r  in  6  n  .  r  a>  oi  ••« 

I  h'HHOO  «*i  C  C_ 
a  m  4J  oi  r  •«  m  a 

k  c  •  m  m  m  in  oi  m  (0 

ai.oimn  —  o  oi  a  ai  u. 

i.gg-SSg-8-SsSj, 

2-,,ss2  8siieaS 

o  "o  l  l  a*>  o  oi  «*■  7 

«£CaaO3LH.  0J* 
044/0  n  *4-  01  44  > 

l  ana  mi**-  n  *0 
«*.  h»  at  w  .  m  a  nun 
Q  >  J  L  'H  >  3  V  it  0  1 

44  M  5  L  M  in  ML 

L44noi4iaiMLO.M 
n3C£U44§0£Oin44 

£aoi44ninn*f44L  ai 

u  44  44  l  n  *•  n  oi  ai 
3  X  >44  33  >•  £  * 

3  o  oi  r  c  oi  mm  h 
Su",“3<xo)ioc44  o 

MC>,ouM£aOy  44 

*•  n  £  0  m  44  n* 

L  01  V  L  in  44 

5  3  M  £  01  C  4  44  100 

n  ai  3  44  l  Dion  e  o  « 
j  n  44  5  no  o  o  y  m 
note  m  luqu 

«  M  L  M  >•  'O  u  L  M 

m  a  44  n  s  oi  >  .  at 

£ccnaoi£MMfli  <4. 
K-Mnai3L  ^  m  m  c  3 

m  4  jm  s  m  oi  u  oi  n 

M3  J4i  C  UO^m 

nrsonau  £  jv 
n  3  44  £  oi  £  a  n  5  oi  o 

niMiftO'4>3e 


l  n  44 

44  n  e 
c  oi  « 


m  l  u  a  u 

>•3  I  L  - 


rv' 


! 

I 


<5 


I 


3 

I 

*fc 

QJ 

I 

O 


|i? 


CO 

'co 


C3 


LU 

i 


O 

u. 


cs 

o 


CO 


CJ 

UJ 


CO 

LU 

CO 


UJ 

CJ 


CO 

5 


u 

H 

CO 


—  C3 


u 

CO  > 


CD 

«  CQ 


m  e 

o>r 


co 

LU 

CO 


UJ 

CO 


O 

cs 


coi 


C/5  S 


CO 

UJ 


co 


o 

TS 


05 


C/3 

CD 


C/3 

C/3 


C/3 


CO 

G 


CO 
«9 
co  O 
o 

05  < 
O  —I 


u 

CD 


CO 

o 


C/3 


<2  co 


CO 


s 

o 


m 
CO  5j 

co  “ 


CO 


CO 


CO 


CO 


CD  w 
05  S  G 
O  O  co 


o 

CD 

_05 

«  g 

S  . 

a  I  ^ 

is  Go 

CO 

2  9« 
£=  S 

c 

S 

C/3 

CD 

05  ^ 
c  CJ 

3=  UJ 

O  12 

*35  «5  g* 

CD 

w 

3 

CO 

■g  **5  i2 
eg  ®  § 

CD 

<c 

J2  2 

iiS  j 

CO 

09 

a;  a.  cs 

*5 

o 

X  LL. 
UJ  ■ — ■ 

®  A  A 

2 

AAA 

• 

• 

• 

• 

CO 


CO 

u 


C/3 

CO 


CO 


u 

CQ 


CO 

i 


CO 


CO 

*33 


CO 


CO 

UJ 


CD  M 

05  as 

G  *kZ 
SO.. 

0 

E 

CO 

«J  c 
3  05 

03  «S  CO 
co  «  o 
eo  G 

C3  re  2 

as 

I 

=?  *33 
jo  ® 

CD  ...  <2  CO 
co  6/3  7^  as 

B  o  w|  = 

as 

H- 

*co 

c  2 

5  5 
2  8/31 

O  _  -  B> 

ll>2  S 

i 

C 

05 

& 

£  «* 
«  5 

2g£o 
£  a  <  6/3| 

'co 

as 

o 

CJ 

S  co 

cg-2 

A  A  A  A 

col 

col 

co|  A 

• 

• 

• 

19  3 


-  -  •  *  •  “  .  "  «  •  •  *  •  "  «  *"  ,  *** k  **  •* 


-»  •Jr  ' 


Lockheed-  California  Company 


AVAILABILITY 


DES I 6N-F OR-SUPPQRT AB I L I T  Y  BASELINE 


44  •  01 

C  C  44 

13 

4  O' 8t  81  k. 

4  at 

4  V  Oil* 

01 

C  44  — 

01  4  a 

C 

C  £  £  81 

UI 

c 

1  L 

> 

01  4  U 

ot  01 

4 

—  44  44  JO 

0>  4 

IB  4 

L  01 

at 

e  £  —  £  £  u 

L  44  C 

C  £ 

•H 

0  0 

— 

ft  44  £ 

44  X 

81 

3  4  Oi  3 

—  1 

—  4 

£ 

—  81  —  Bl 

01  >  81  Z 

*  >  • 

C  4  ft  W 

tm  —  l  r  8  « 

—  —  —  £ 

8)  4  U  44 

81  M  L  ttl  >■ 

£4  B)  U  C 

•u  a  o  -w  «  4 

£  £  « 

«m  o»  a  s 

o  a>  —  a 

44  C  H-  C  L 

—  C  — 

etc 

aoioo 
o  «  .h  >  g  c 
r  -  u  ui  t  - 
an  */ 

01  ft  £ 

£  *t  in  ■  £  cn 
m  l  xa  *t  — 

5  80  >*■ 

§  §:**  8  Js 

V.  3  <8  01  k.  I 

‘♦•in  £  **■ 

a  m  c 
oi  ia  «  $ 

S  s-i 

c  -u  — 

2  >9^1 

6  ^  U  4  ft 

ll«M  C  L" 

C  —  ft  Oi  £ 

oi  l  tj  a  a 
*•  m  **  e  o  u 
<«  oi  u  a 

♦J  a.  oi  S'  c5  > 

0)  £  -O  44 
L  44  — 

in  >  c  — 

3  >  O'  — 

O  a  £  it  —  £ 

v.  >+•  «  in  g 

L  44  —  £  81  • 

4  —  Z  83 

<—  0 

-  44  0  • 

or  £  l  +>  — 

£  4  «  in  £  i 

H  —  £  C  C  4  I 

—  44  c  #  c  ; 

4  01  -  >  6 


or  >♦.  u  £  c  >•  #  u  ~  i  a  u 

—  i  44  —  <♦  lmIi.  c  4 

■O  9-  0  >44  —  4  L  UJ  or 

38  0!%0{J£|2^t 

*i  5  -CO  3  O  > 

it  i  “o  u  a  or 


0  41  L3 

«  —  i  • 


CT)088l88tl  TJ 
£  ft  -M  a  C  L«  *> 

u  in  4  •  9  >«f  to  oi  01 

l  8  u  —  £  0  -  in  ft 

4  £  81  U  £  81  ft  44  —  £ 

in  8Q4i  L3  C  e.'H£  1 

in  tnm— ft«aa  —  h 
oa-nzr£-L-  c 

L  n  8  8  1  on  3  U  4 

4  g  —  ui  4  <01 

in  si  c  -4  c  «♦■»>- 

•  n  1  jrt  8  a--  c  n  u 

a  c  a  £  ■  —  4-  —  * 

Lf  k.  O  41  O  8t  8i 

9nOkL£U88'4 


U  on  8  a  u  entfl 

£  C  4  81  —  C  01 

■o  3  0  81  at  i  £  *»  01  a 

Sin  a  £  £  u  at  ►-  £  me 

£  44  t-  £  OI  M 

«  -«  _  -J  -  01  £ 

•4  ft  >  •  □  C  •  44 

4££_tS9-.LC-C 

•  44  □  U  4  8  3  2  OI 

n  j  ts  a  8  nil  — 

l  s  f  01  4J  «  -in  in 

92  on  m  ;£>♦  c  k  n 

a  L  C  £  8  I  O-Oi'D 

•  ft  44 

l  9  in  44  e  v  ft  —  z 

o  u  01  -u  -  *1  m  £  at  oi 

Q  k  C  k  8  8  8  3  n  £  C 

0  •»  —  a  —Du  —  in 
5  —  ft  01  £  O  ”0  *  81 

N  ft  k.  C  ft  H  —  Oi  V  L 

mm  —  e  —  n  "ft  ft  •« 

1  44  4  w  —  —  •  0  c  i  >  g. 

U  C88  «<4<4U  8  80  7 

l  S  inaiQ«*+raiQi* 
9  I  8«>  8  8  k  C  —  Ok 
u.  3  r  j  £  4  *j  n  -  jsa 

k  0  Sou  5  u  ft  ft  — 

—  *0  <4  I  8  U  £  — 

C  e  L  £  44  81  Ui  z 

—  0  4t  1  8  *IW  , 

at—  c  —  u  »  k  -  4  8  . 

£4  3  1  «  k  8  9  on  e 

H  —  8—  C  8  9d|k  □ 

U  W  4*  or  U.  T  .in 

—  C  4  -  «  .  OG  8. 

v4uinjk.w®KKin. 

v  £  3  ©  B  -  8  a  «•«  4 
O  U  —  T)a«£UZZ£ 


<r  - 

-  81  X  . 
4  £  £  _J 
••MO 


U  C  -M  in  4 

4  81  —  C  OI 

£  4t  8  o  1 

ft  K  £  in  £  O 

£  or  «  L 


5a? 


>  o»  in  - 

801k 
*  44  "O  TJ 


in  —  *t  « 
at  k  c  £ 


197 


I 

r’ 

r,' 


v: 


■ 

i 


r 


f 


*  ■  *,  «'v  ."(  .*  -t 

**■>•.  V  *  **"  - 


r 


I  Ol  L  £  • 

:  £  u 

I  44  «  44 

*  x  u 

I  01  £  44 

i  xi  44  g> 

i  ■**  to  Q 

-  3  44  U  -4 
I  01  «  •« 

I  £  44  £ 

4i  •  U 
10  —  3 

4JQtk.cn 
Ol  01 
I  U  L  44 

I  -  q»  U  • 

g»  v  <»  oi 

.  0  £  L  » 

I  M  <0  3 
01  £ 

'  Ol  £  U  £ 
i «  *»  n  i 

£  III  *0 

•  <o  to  at  c 

•  4j  ia  l  at 

13  3  4J 

**■  £  44  C 

I  01  01  *  •* 

i  l  c  at 

L  44  >♦-  L 
I  •-  H-  O 

i  at  •+. 

•  £  £  C  ^ 

i  in  a>  > 

it*  HI  44  44 
I  •■*  f*  m 
rjj  at  - 
i  to  cn-o  — 

.  4 *  £ 

i  in  u  to 

.  01  0  UM  44 


at  o  w 

£  44  u 

44  44 

£  44 

3i  ■ 

-  §2 
Ot  u 
in  l  ot 

u  L 

in  it 

4J  -m  £ 

w  u 

•*4  X 
L  U  £ 
01  C  44 
44  G  0 
U  *4  £ 

ig  u 

L  4,  £ 

<0  >4-  C 

£  *«•  <o 
U  3 

in  c 


L  A 

at  e  £ 
■°  i  o 

0  44  U 

:i* 

L  44 

to  •  10 

£  •  L 

UU 

10  44  44 

4*  £  C 

£  a»44 
44  ~4 
*L 

s!'i 

44 

£  <0  Ot 

.  at  ,  £ 

44  G  44 

§  S  at 

w  a»  > 

at  i  ot 

L  44  — 

a  x  £ 
at  oi  u 
.  l  e  <o 


•  ot  x  £  ot  £ 

at  m  u  k.  £  ot 

44  Ol  44  5  44  44 

H  £  -4  0  ig 

L  44  3  £  k. 

i*  1  Ol  0» 

L  C  >  Ol 

S£  0  Ol  44 

Ol  X  .4  C 

-  >  £  C  £  44 

44  oi  v  m  u 

■0  44  M  ig 

L  £  10  £  01 

i  U  U  C  0  £ 

C  •  10*4*4 

oi  -w  £  -a 

0  U  Ol  Ol  Ol 

01  44  oi  L  L  > 

44  44  44  44  01 

**  *2  2  - 
o  oi  oi  oi  u 

*  L  £  L  L  to 

44  L 

£  3  tO  0 

at  S’  o  oi  in  o 

44  01  £  k  *4  4t 

£  L  I  3  10 

£  8  in  in  0 

at  01  01  .4  £ 

C  L  L  01 

4#  IQ  4.  3  44  Ol 

«  01  44  (0  c 

44  u  10 

in  in  c  oi  a 

3  oi  <o  m  x 

m  k.  44  o  u 

3  in  c  w  c 

01  44  C  0  01 

>  <0  44  44  S  -«4 

01  01  44  0)  U 

44  *4-  It  44  -4 


S  8 

<0  c  u. 

at 

0  44 

44  «  t 

oi  in 
£  u 


u  m  *4- 

oi  XM. 

Sin  s 
m 

*§: 

L  44  p4 

Ol  44  01 


C  I  01  £  44 

Ol  C  £  U  <0 

>  5  3  3  44 

Ol  n  II  U 

U  44 

L  Ol  <*• 

COL  44 

9  **  a  a»  44 

X  CL 

to  c  o  m  « 

44  a  44  0 

44  S 
£  44  £  m 

C  3  9  L  £ 

E  04  44  Cl  L 

a  io  a  rg 

£  in  u  l  2 

oi  o  a.  a 

6  C  -  44 

E  Ol 

10  44  01 

l  in  £  . 

at  oi  3  a 

0  £  44  o.  HI 

l  w  a  4J 

a  oi  3  in 

£  s 

L  44  Ol 

oi  in  £ 

44  ID  44  44  44 

3  44  c  m 

a_  oi  l 

E  3  >  X- 

o  a.  £  >4- 

u  «  x 

Ol  C  o  £  01  oil 

£  to  44  9  £ 


£  ■*»  z  io  m 

9  44  0  L 

l  imtn  a  S  c 

44  44  Ct>  L 

3  L  U  01  a  3 

or  i  4  gt  44 

a  C  44  44 

L  44  u  10  C  0)  44 

to  to  E  01  0  Ifl 

•  l  >S  3  x  at'! 

L  01  £  C  X  01  0 

<o  u  u  a  o  £  u 


£  10  44 

C  -4 

9  44  Ol 

U  3 

• 

U  01 

44  U  V 

at  C  £ 

0  10  44 
f*  44 

in  c 
c  a 

01  44  £ 
>  44 

0  b 
£  0  » 

0  Ik  k 


Ol  •  0 

£  l  a 

H  01 

£  £ 

t  * 

3  0 

<4-  £ 


44  0 

c 

o*  in  a* 

•P4  .M  C 


01  s 

cum 

•po  L 

Ol  QI  Ol 
£00 


in 

l  oi 
0  11  u 
a -4  c 

A  £  01 

>  <0  01 


44  0  01 
01  L  44 

3  L  C 


V.-' 


nave 

-  £  a  w 
■u  u  _i 

L 

X  3 

u  >4J  a 

c  £  *  £ 
a  a  jj 

•—  V 

U  £  v 

•-  a  c  o 

*4-  o> 

H>  K  h  C 
3  -  «  0 

III  >4  ll  K 

l  £  in 
v  c 

—  in  a 

ti  igaiii 

X 

£ 


U! 


> 

u  a  a 

y 

L 

3  £  C  £ 

z 

0 

Ul  44  a  44 

u 

V 

44 

a  v  a  a 

a 

■a 

Ol  0  -  L 

ft 

a 

c  a 

lu 

c 

—  c  a  -0 

L. 

CP  £  0  X  - 

3 

■■4 

44  ■—  0  a 

cn 

a 

44  L  C 

1 

a 

C  4  L  a 

Ul 

■0 

0  U  4  U 

-J 

Ul 

a 

x  v  e  £ 

ft 

•at 

U  -*  £  6i 

C  44  44  a 

44 

a  c  £ 

3 

4 

■0  a  v  -x 

£ 

c  £  0  u 

44 

a  •-  0 

v  a  <ai\  me 

C4mh  maw 

4  C  U1J 

*  0  L  •-  3 

C  •—  0  44  — 

C  O  4i  f  fl  U  dl 

0-4  4  >4  c  £ 

■—  *t  n  a  l.  •-  *> 

U  3  *4  >H  (1 
4  -  CU4I 
U  0  4  -4  u  £  V 

-4  a  a*  a  4  u  q 

V  "X  L  C  L  4 

a  0  0  4  Q 

a  Q.£  L.  <~ 

u  a  u  a  x 

3  w  a  a-a 

_  *i  _J  k.  C  4  3 

«  4n  a«  _  x 

a  *  -  <t  ft 

V  -H  ID  U1 

*o  a  _j 

c  c  c  tj  a 
_40  a 
"0  3 
on  +i  cm  a  **' 

C  4  U 

-4  N  c  01 

1  -  6  4  C 

a  c  o  £ 

a  4  l.  c  c 

c  o"+-  a  c 

■M  L  *44 

(TO  m  o 


c 

a 

•o 


44  01 


a 

a 

£* 


X 

<x 

E 


a 

a 

a  -o 


•u  _t 
•  £ 
a  cn 


a 
a 

a  . 

£  c 

44  U|  O'- 

c  44 

**•  c  ■—  <-• 

0  CJI  L  3 
•m  a  a 
a  a  a  a 

L 


c  a 


U  V.  L 
-4  V  4 

£  0  £  a 
a  u  £ 
>  ** 
a  a 
a  £  o 

U  l.  44  44 
-4  V 

4  C 

o  a 

c  4  a  § 
«  £  - 
5  a  4J 
a-43 

Sso 

a  £  a 


-  a  c 
a  a  - 
x  o>  a  j 
x  c  o> 

•  4  £  UJ  4 

X  C  3  » 

£  4  4j  c  o'  a 

3  L  01  C  C 

44  v  0  •—  4  Q 

ft  v  v  a  *+  •- 

Ova  44 
a  a  a  o  c  s 

a  u  a  — 


c 

a*  4 


_  _  a 

-X  u 

a  a  c 

4  a  a  — 

k  -o  £  « 


0 

e  a  £  a 

•-  £  4  V 

0  44  u  a 

■n  -—a 

V  k. 

-  3 

U  44 

a  4 
a  a 
a  v 


Design  Engineering  in  the 


qjr Lockheed- California  Company 


QUICK  INTEGRATED  COMBAT  TURNS 


^Lockheed- California  Company 


Lockheed-  California  Company 

SUPPORTABILITY  (S)  AND  S  RELATED  DESIGN  FACTORS 


0 

UJ 

Pz 

CO 

Tz 


u 

<  x 

S  UJ 


z  < 

$2  z 

co  s 

Ui  Z 

o  -i 

s  o 

H  UJ 

<  N 

O  i 

8  I 
3  * 

§  I 

^  z 

co  5 
o  S£ 

i  i 

PC  CO 
UJ  £ 

O  UJ 

<  CO 

<  1 
o  s 

£  < 
s s 

o  • 

oc 


o.  O  co 
<O0 

OC  -O 
hWffl 

coog 

o  £  co 
Oc  t£ 
m  z  ui 

<QJ 


83 

O  -J 
Sa 


PC  co 
UJ  •£ 

lUHlL 

u.-  < 

“XOC 

>*520 
H  OC  OC 

<2Z 
3  CO 

*  UJ  UJ 

zu  s 

<2u_< 
z  O  co 


s.  2  CO 

olio 

<  <0  H 
UJ>  CO 

«5o 

fai 

oa  s  “ 

sgi 

Oa< 

X  CO 

s°» 

“Is 
2  «*  •* 
SCO  CO 
*  CO  X 
—  UI  O 
><  O  UJ 

<ox 

2<0 


UJ  CO 
o  UJ 
cc> 
Oh 
U.O 
rr  UJ 
=  “» 

<8 

■  ■  w 


i 


—  SDTRs  TRACKED  BY  CALLA  AND  TRADEOFF  EVALUATED  USING  KELSA 

—  TAILORED  SPECIFICATION  LANGUAGE  FROM  TRADE-OFF  EVALUATIONS 
SUSTAINED  HIGH  SORTIE  RATE  =  ALL  OF  ABOVE 


I 


u 

ai 

L 


K) 

O 

N 

X 

w 

<t 


<x 

in 

p 

i 

tn 

in 

> 

i 

1 

2 

4 

5 

i 

u 


6  III  >« 
m  »  —i 
P  X) 
ui  % 

>.  ai 
in  £ 
a  - 
U  "0 
C  0 
0  P 
III  111 
•** 

L  • 

A  Oi  p 
a  3  « 
6  -«  £ 
0  id  P 

U  >  «d 
01  P 

C  -0  <11 
-  01  U 

4-1  P 

01  -  ■O 
Ifl  E  01 
id  ■*  p 

D  m  d 


>.  o'  a>  cni 

■o  c  £ 

3  •«  H 


id 

3 

ifl 

3 

01 

£ 

P 

P 

id 

£ 


III 

Oi 

P 

a 

c 


in 


in  in 


■a 

01  *3 
U  01 
->  C  P 
Ul  ffl  fl 

S  c« 

^  01  i. 


01 

Ifl 

3 

T3 

01 

01 

£ 

.¥ 

U 

0 

_l 

ai 

£ 


£  P 
id 
in  3 
o  01  p 
P  id 

p  > 

«4  01 

P  c 
U  3  * 
ai  p  oi 
a  l  -a 
in  o  3 

oi  a  p 
l  a  u 
o  c 


£ 

P 


01 

k. 

c 

a» 

■rt 

111 

ai 

TJ 

Q 

P  • 
P 

c  m 
3  Q 
0  u 
XJ 

■o 
in  c 

p  Ifl 
01  _ 
0>E 

* 

u  oc 

GQ 


P  3 


01 

P 

•d 

U 

■04 

£ 

C 


Id  Ifl 
U  Ifl  • 
X  01  Ifl 

ouo: 

O  Oh 

OI  la  O 

o  atn 


Ul  -a*  P 


4 
01 
P 

§01  u 
£  p 


U 

11 

w+  *aO 

p  -a 

P  oi 
L  -0 
is 


£ 

U 


> 

0  ■ 
L  • 

a 


£  Ifl 


> 

a 

■a 

oi 

£ 

■04 

L 

U 

Ifl 

01 

13 

Ifl 

ifl 

Ifl 

01 

L 

3 

P 

ifl 

01 


c 

0* 

*00 

ID 

01 

TJ 


I 

i 


207 


SUPPORTABILITY  DESIGN-TO  REQUIREMENTS  (SDTRs) 
PROCESSING  TO 

DETAIL  MODEL  SPECIFICATIONS  AND  LSA  "A"  SHEETS 


1  C  TJ  T3 
01  O'  C  0) 
T3  «  L 
4  I/I  0 
L  5  - 

44  Q  0  — 

—  (fl 
C  44  44 

CP  01  4 
—  £  L  01 
UM  31 
oi  »*- 

?sss 


in  c  n 
ai  in  o»  u 

>  4  —  3 
»  O 
■u  01  — 
<0  TJ  4- 
CO  c 

l  ui  ai  a 

01  _J  £  U 


«  ai  r  £ 
v  +>  +* 
h-  c  a 
0  3  0  0 

So  oo 

•*«  Ql  *v  — 

44  *>  L 


«  c  •  u 
44  v  —  in 

Sfi  a  ai 

3  -  TJ 

~  y  in 


11  L  L  C 


£  in  c 
cp  oi  c  a 

8  in  o  - 

>  —  44 
£  —  44  4 
44  4  4  U 
—  C  N  — 
C  4  ■«* 

c  - 

<0  u 

4-  CP 


L  — 

u  c  ai  l  —  ai  — 

o  ai 

CP  O'  0  OJ  >  — 

<4-  TJ 

44  —  4  13  4  — 

0 

in  in  3  o  £  x 

c 

—  ai  at  6 

in 

at  tj  c  in 

•*» 

o  4  —  in  c 

in  >4 

**  —  in  —  £  oi 

<0  ■- 

01  4  —  01  £ 

£  4 

£  C  £  4  01  *i 

*4-  a  4J  £ 

01 

o  —  "a  oi  in  >> 

0)  TJ 

44  44  01  T3  — 

£ 

in  4  4i  i  c 

44 

in  3  u  4  a  o 

01 

01  6  —  —  01  * 

£ 

L  <4*  01  £ 

01  44 

3  -  LUO  « 

L 

in  >.  u  co  c 

4 

4  11  11  C  £  a 

0 

ai  £  a  cp  c  - 

in  £ 

e  m  m  —  s  ai  *» 

>4-  C 

in  £  £  u 

<4>  — 

>  (01  01  3  44  01 

0 

—  »  TJ  i-i 

SI  C 

c  >-ti  a  a 

-o  0 

o  *i  v  tj  4J  in 

m  — 

—  4  —  • 

L  44 

c  -a  •  —  in  c  l 

■u  <0 

—  —  O  4  £  O  O 

••4 

4  —  £  >  U  —  4J 

C  44 

44  4  01  44  u 

a*  o 

C  >  £  4  4-  3  4 

-  CP 

O  U  H-  £  L 

in  oi 

U  4  TJ  «  —  44 

01  c 

a  o  -a  v.  c 

TJ 

4  >  L  4  44  0 

• 

44  4  a  u  in  u  q 

oi  3 

01  £  &—  —  — 

(0 

£  >4- 

01  4  -  44  ■O  L 

u. 

4J 

£  —  in  3 

in  a  -a  s  -  an  4* 

L 

01 

44  u  at 

a 

1  01 

*  v  »  o  »  v  •+ 

3  4 

C  £  44  —  44  — 

L  3 

<  01  40  a  —  £ 

> 

H-  a» 

in  u  oi 

•a 

c 

«  oi  o  £  >*.  -a  >* 

4 

<0 

cn  £  _i  w  a  c  - 

01 

0>- 

£  44  4  01 

L 

c 

01  i  > 

•M  i 

£  <X  W  - 

01 

288 

28ti 

£ 

3  — 

—  u.  C  3  —  44 

e 

in  4J  4J 

44  •  (0  in  44  01 

4 

8  4  4 

m  oi  4  4  a 

L 

L  U  U 

—  •  —  01  U  8 

a 

—  — 

x  in  £  oi  f  -  o 

a 

4»  «4* 

ai  44  4  £  —  u 

L 

in  —  — 

U  44  44  — 

a 

CC  u  u 

0)  4  y  c 

H  01  01 

01  *4>  -  01  OJ  SI 

01 

a  a  a 

£  <4.  01  0  £  a  01 

£ 

(fl  in  in 

H  01  L  44  44  in  £ 

44 

SUPPORTABILITY  DESIGN-TO  REQUIREMENTS  (SDTRs) 

PROCESSING  TO 


DETAIL  MODEL  SPEC. 


f 

f 


As  ‘O 

2  c 

©  CO 


11 


<0|- 
©  CD 


CO  CO 


0)  9 
©  g 

■O  CO 


s  § 
H  s 
<  2 
»2  a 


&  *2 


i  a 

a> 

>•  © 

CO  JC 

E  o  « 
x  tl  © 

5-S.s 


w  o  £ 

S  *  : 

C  C  CD 

~  co  co 

®  ft  3 


a 

© 

E  & 

S  (01 


$  CO 
o.  fcu 


a  ?  2 


I  g 


E  o  a 

o  c  g 

O  ©  § 


III  C  TJ 
“  © 

•£  fi  * 

2  8  I 

®  w  C 

o  o  « 


To  co  — 
•2  co  jo 


|  «2 

S  3 

§  O' 

8  2 


SJff 
©  ©  o 

•O  3  £ 

£  O-  ” 

*  5 

S2  co  o  n. 
DC  =  ©  o 


O)  ©  <0| 

iS  £  -g  *0 
w  C0  J3  DC 

COI  s  It 


©  *d 
©  >» 


w  2  5)Q 
o  g-  ©  <o 

O  o  (0  > 
CO  DC  CO  .a 


O)  w 

£  © 
<0|  to 


2  *5 


©  © 


2r  <o 


uj  jg  ■=  j2 
S  «Sc 

—  ©  is  © 


c  A  A 

O 

O 


CO 

£  A 


©  JZ 
Q.  O 
X  © 

©  H 


=  e 

1  s 
I  w 

a  ° 

5  ? 

o>  ~ 

"E  S 

O  (Q 

o  ■ 
<01  g 

O  C 

r  o 

a  © 


©  © 
o>  © 
© 

§»  | 

!£ 


AAA 


C  JC  =  > 

a.  h-  5  © 


,v  .  ’■  «*•  ,*•  ,  • 


\  ^  ■  •  -  ■  -  -  -  - 


ING  FOR  SUPPORT ABILITY  IMPLEMENTATION 


i  t 


i  r 


0  C  £  X  T3 
-«  01  **  £  C 
< 

0  •  4J 

£  C  U  H- 

■o  ~  tn  « 

C  «  J>t-  11 
0  UJ  £ 
£U  0* 

X  -M  01  0 

*t  3  £  0  44 
•m  +»  44  £ 


•-  TJ  0 

£  *4-  Q  mt  44 

0  0  3  - 

t«ll3 

6  V-  0 
a  3  -w  0 

a  **  I  §  o 

0  0  0 


.  £  44  *1  4J 
L  44  3  0  0 

3  0  N  L 

C  3 
I  •*  C  C  O*  • 

C  0  0 

a  0  o»  »♦*  0 

-i  g  tj  l  c  ai 


0-0 


c  o 


8  8 


TJ  44 

X  L 

u  r 

l  cni  a 

ft  3  « 

44 

£LU 

0  «  c 

*»  44  X 

3  0  0 

0  a 

■o  - 

t  c  « 

C  £  44 

**  u  •»* 

3  0 

ft  £ 

0  pt 

>  ft  44  TJ  3 

•p*  T3 

44  •*  S 

s  .s 

y  3  . 

0  0 

a  o>  ft 

4-* 

-»  0 

X  C  ft 

£  3 

L  ft  £ 

0  ft  . 

0  >  44 

•  tt  >♦.  ~  cni  o 

5>  ** 

•  *i  S  CK  0 

”  J.-1 

obi? 

44  <4»  44  0  ft 


212 


'•  ,  '  %  v;*-' •• 


v* 


REPORT  NO.  19 


1 .  Creating  the  Logistics  Information  Model 

A.  FINDINGS 

The  CALS  Technical  Issues  Subgroup  feels  that  the  critical 
importance  of  logistic  data/information  to  prompt,  accurate  and 
effective  decision  making  on  weapon  systems  is  strong 
justification  for  developing  a  general  logistic  information 
model.  This  model,  therefore,  is  an  important  technical  issue  in 
itself  but,  more  imporantly,  it  becomes  the  essential  tool  for 
identifying  and  characterizing  other  critical  technical  issues. 

The  Subgroup  considered  many  other  technical  issues 
involving  1)  development  of  standards;  2)  data  base  systems;  3) 
networking  procedures  and  4)  procurement  practices,  but  concluded 
that  these  issues  were  being  addressed  by  other  CALS  Subgroups  or 
by  the  ongoing  efforts  of  the  DoD  and  industry.  The  concept  of  a 
logistics  information  model  is  a  technical  issue  that  is  central 
to  the  interests  of  the  entire  logistics  community. 

The  Subgroup  recognizes  that  many  data/ information  models 
exist  (mostly  diagrams  or  charts)  which  address  various  aspects 
of  weapon  development  but  none  of  these  models  addresses  the 
specific  logistic  needs  that  require  attention.  These  other 
models  and  several  other  sources  of  appropriate  information 
constitute  a  valuable  source  of  data/information  for  the  proposed 
logistics  model.  Select  such  sources  are  listed  at  the  end  of 
this  report. 

Additional  findings  are  reflected  in  the  following 
recommendations,  which  are  summarized  and  given  time  and  funding 
estimates  in  the  attached  table. 

B.  RECOMMENDATIONS 

Develop  of  the  proposed  logistic  data/information  model 
requi.es  at  least  the  following  steps: 
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A  listing  of  all  the  logistic  tasks  or  functions  that 
must  be  performed  on  a  generic  weapon  system.  (Tasks 
to  be  drawn  from  MIL  STD-1388  1 &2 ;  DoD  directives 
5000.39  &  .40  and  other  sources.) 

An  identification  of  all  the  data/information  sets  that 
are  required  to  perform  the  tasks  listed  in  step  1 
above . 

Verification  that  steps  1  and  2  above  are  adequate  to 
cover  - 

a.  Work  on  all  of  the  defense  weapon  systems  and  sub¬ 
systems  that  are  required  for  the  national  defense 
—  including  foreign  weapon  sales  and  cooperative 
production  programs 

b.  All  phases  of  each  weapon  system  from  its  earliest 
concept  through  final  disposition  —  including  any 
engineering  changes  to  accommodate  1)  new 
militarythreats;  2)  error  corrections;  3)  new 
technology  insertion  or  4)  modernization. 

c.  All  modes  of  defense  product  documentation  or 
representation  that  are  employed  --  including  1) 
totally  manual  (hard  copy)  2)  mixed 
manual/coraputer ized  and  3)  totally  computerized 
modes  as  well  as  4)  vector  or  raster  display. 

d.  All  types  of  data/information  that  will  be 
required,  including  1)  graphics;  2)  text;  3) 
tables;  4)  mathematics;  and  5)  product  models. 

e.  The  dynamic  flow  paths  of  the  data/information 
from  a  typical  repository  through  its  various 
transformations ,  back  to  the  same  or  to  a 
different  repository. 

f.  Representative  types  and  volumes  of 

data/ informat  ion  required  in  the  various  tasks. 


g.  The  most  frequent  used  and/or  the  more  critical 
data/information  paths  and  operations  versus  those 
that  are  less  frequently  used  or  less  critical 
(this  will  identify  the  so  called  "hot  paths"). 

h.  All  restrictions  placed  on  the  involved 
data/information  such  as  for  1)  model  integrity; 

2)  proprietary  limits;  3)  national  security;  or  4 ) 
export  regulations. 

i.  The  necessarily  changing  character  of  similarly 
labeled  data/information  as  it  proceeeds  toward 
product  maturity. 

j.  Assurance  that  the  model  and  its  components  can  be 
updated  rapidly  as  the  embedded  technologies  and 
the  logistic  procedures  develop. 

k.  Assurance  that  a  capability  exists  of  handling  or 
working  around  data/information  related  to  the 
technologies  employed  in  advanced  defense  products 
( VHSIC  and  optical  technology). 

4.  Identifying  the  technical  limitations  of  --  or  the 
barriers  to  —  application  of  the  model.  Characterize 
the  limitations  and  barriers  in  terms  of  their  possible 
resolution  by  1)  coordination;  2)  R&D;  3)  contract 
statement;  4)  directives;  or  5)  a  combination  of  the 
above . 

5.  Survey  the  industrial  and  Service  assessments  of 
technologies  that  relate  closely  to  the  model  (computer 
hardware,  software  and  firmware;  protocols,  languages 
and  data  base  systems). 

6.  Explore  the  early  demonstration  potential  of  the  model 
—  especially  by  association  of  the  model  (or  a  section 
of  the  model)  with  appropriate  ongoing  weapon  projects 
that  might  both  utilize  and  share  the  benefits  of  such 
an  exercise. 
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7. 


Set  out  and  report  on  the  criteria  for  assessing  the 
measures  of  improved  weapon  effectiveness  that  result 
from  use  of  the  model. 

8.  Provide  a  basis  for  justifying  the  model  by  applying 
step  7  to  real  world  problems.  Report  on  the  project 
to  this  stage. 

9.  Prepare  a  plan  for  implementing  a  practical  pilot  model 
including  a  report  on  the  model's  capabilities  and 
limitations  as  it  employs  "available  technology"  in  its 
application  to  typical  weapon  systems. 

10.  Demonstrate  defined  features  of  the  pilot  model  and 

report  on  the  objectives  that  were  achieved  1)  wholly; 
2)  partially;  or  3)  that  were  passed  over. 

11.  Present  a  plan  for  the  further  application  of  the 

model. 

The  Subgroup  further  recommends  that  - 

1.  The  steps  listed  above  be  coordinated  thoroughly  within 
the  CALS  Group  and  among  the  Services  and  the  DoD 
agencies  during  processing  of  the  project  by  the 
implementing  office. 

2.  A  single  military  Service  be  delegated  the  contract 
implementing  responsibility  for  this  project.  Subject 
to  the  interests  expressed  by  the  individual  Services 
and  their  ability  to  reach  a  concensus,  the  Subgroup 
recommends  that  the  U.S.  Navy  be  assigned  this 
implementing  responsibility,  because  of  its  operational 
use  of  such  a  wide  variety  of  weapon  systems. 

3.  The  proposed  11  steps  (or  their  revisions)  be 
implemented  in  2  phases  including  steps  1  thru  8  and 
steps  9  thru  11.  These  phases  should  be  parts  of  a 
single  contract,  although  with  some  modification,  they 
might  be  two  separate  contracts 


The  total  project  outlined  on  the  previous  page  is  estimated  to 
require  funding  at  the  level  of  $250,000  to  $300,000  and  take  1 
calendar  months  from  date  of  contract  authorization  for  its 
completion. 
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Figure  1.  THE  GENERAL  LOGISTICS  INFORMATION  MODEL 


SELECTED  REFERENCES  FOR  THE  LOGISTICS  INFORMATION  MODEL 


1.  Evolutionary  Development  of  Computer  Aided  Support  (CALS)  - 
dated  October  1,  1984  -  by  Darrell  Cox  (Rockwell) 

2.  Computer  Aided  Logistics  Systems  Supportability  —  "A  New 
Dimension  in  Design  (3  layout  sheets)  -  by  Erich  Hausner 
(Lockheed ) 

3.  Acquisition  Process  for  Major  Defense  Systems  -  a  layout 
sheet  dated  July  1934  -  by  Booz-Allen  &  Hamilton,  Inc.,  via 
Darrell  Cox  (Rockwell) 

4.  Acquisition  Life  Cycle  Technical  Activities  by  Mulak  -  a 
layout  sheet  via  Darrell  Cox  (Rockwell) 

5.  Logistic  Support  Analysis  Application  Guidance  -- 

MIL  STD  1388  1A  -  a  layout  sheet  dated  March  1984  -  by 
DARCOM 

6.  Flow  of  Information  in  a  General  Logistics  Information  Model 
-  a  layout  sheet  with  comments,  dated  October  1 8 ,  1984  -  by 
Darrell  Cox  (Rockwell)  and  George  Beiser  (IDA) 
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REPORT  MO.  20 


DEVELOPING  DESIGN  INFLUENCE  ALGORITHMS  FOR  LOGISTICS 

A.  BASIC  PREMISE 

Existing  R&M  influences  have  not  had  sufficient  design 
influence  to  assure  fielded  that  systems  exhibit  high  sortie 
generation  rates  or  other  measures  of  effectiveness. 

Assume  that  the  application  of  the  developed 
algorithms/computerized  LSA  system  takes  place  prior  to  PDR,  and 
that  these  applications  then  keep  pace  with  the  design  process. 
Phases  of  the  application  should  be  consistent  (i.e.,  in  levels 
of  detail)  with  the  acquisition  process  -  from  conception  to  0&S. 

B.  FINDINGS 

1.  The  design  of  weapon  systems  occurs  in  a  tightly  compressed 
schedule  environment  in  which  the  supportab i lity  influence 
must  be  exerted.  The  use  of  computers  will  enhance  this 
process  by  integrating  various  design  and  supportabi lity 
functions . 

2.  A  variety  of  data  bases  exists  which  serve  diverse 
functions.  It  is  necessary  to  extract  specific  data 
elements  for  use  by  various  disciplines  from  product  concept 
formulation  to  customer  feed-back. 

3.  Many  models  exist  today  which  are  used  as  peripheral  tools 
to  assist  the  designer  and  supportabi lity  engineer.  These 
models  impact  various  phases  of  the  acquisition  cycle  and  it 
is  necessary  to  ascertain  if  the  algorithms  in  these  models 
can  be  integrated  into  a  large  scale  model  with  mulit- 
purpose  capability. 

4.  Logistics  requirements  can  be  extracted  from  the  CAD/CAE 
that  affect  the  generation  of  LSA  sheets  and  cards. 
Furthermore,  the  design  of  support  equipment  and  training 
devices  can  naturally  follow  from  the  defense  product  design 
information . 


The  design  algorithms  must  be  specifically  tailored  to 

address  the  intended  use  of  the  system;  its  operational 

environment;  its  integration  with  lessons  learned  and 

statistical  data  feedback. 

C.  RECOMMENDATIONS  AND  PROPOSED  SCHEDULE 

1.  The  object  of  the  Design  Influence  Algorithm  technical 
issue  is  to  document  the  inadequacy  of  the 
logistics/design  interface  by  referencing  lessons 
learned,  the  less  than  adequate 

availability/reliability/maintainability,  and  to 
document  by  hind-sight  what  could  have  been  done  with 
adequate  early  information. 

2.  Industry  and  services  have  been  aware  of  the  problem 
for  sometime  and  have  already  embarked  on  some  forms  of 
solution.  These  need  to  be  reviewed  to  establish  where 
overlaps  or  gaps  exist,  and  to  understand  clearly  the 
current  capability. 

3-  Existing  design  algorithms  must  be  identified  and 

evaluated  for  applicability  to  the  CALS  effort.  To 
effectively  use  the  algorithms  a  data  base  must  be 
found  which  contains  adequate  LSA  information  to  design 
numerous  widgets. 

4.  Where  the  existing  algorithms  do  not  meet  the  CALS 
requirements,  new  algorithms  will  have  to  be  developed. 

5.  In  the  event  that  an  existing  data  base  contains 
insufficient  LSA  information,  a  new  data  base  will  have 
to  be  built  with  consideration  being  given  to  the  needs 
of  CALS. 

6.  For  these  algorithms  to  be  tested  properly,  several 
different  weapons  systems  (or  subsystems)  must  be 
designed  across  the  various  design  functions. 
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The  demonstration  of  the  use  of  the  defined  algorithms 
is  seen  as  a  relatively  short  span  period.  It  will 
test  the  effectiveness  to  the  designer  for  designing 
the  various  weapon  systems  with  supportability 
considerations  early  in  the  design  process. 

Upon  conception  of  the  design  product,  the  item  will  be 
placed  in  service  at  which  time  the  predetermined 
measures  of  effectiveness  (MOE)  will  be  assessed.  In 
the  event  the  product  exhibits  an  excursion  of  the 
selected  parameter  beyond  the  expected  design  range, 
original  design  algorithms  will  be  rechecked  to 
ascertain  the  discrepancy  or  oversight.  As  part  of 
this  algorithm  validation  it  will  be  necessary  to 
correlate  the  test  environment  with  the  operational 
environment . 

After  validation  of  the  algorithm,  the  system  must  be 
installed  at  some  location,  used,  updated,  and 
finalized  for  use  in  the  logistics  community. 


DESIGN  INFLUENCE  ALGORITHMS  SCHEDULE 


Mths  from  go-ahead 

1.  Document  problems 

2.  Investigate  existing  programs 

-  Industry 

-  Service 

3.  Identify  and  evaluate  existing 
algorithms  and  associated 
data  bases 

4.  Develop  additional  algorithms 
to  meet  shortfall 

5.  Develop  composite  data  base 
(if  existing  data  bases  are 
insufficient) 

6.  Identify  products  to  be  designed 
for  demostation 

7.  Demonstrate  the  use  of  defined 
algorithms  for  candidate  products 

8.  Validation  of  algorithms 

9.  Finalize  and  install  system 


223 


REPORT  NO.  21 

DEVELOPING  A  LOGISTICS  WORKSTATION 


A.  FINDINGS 

The  logistics  workstation  will  be  expected  to  support  DoD 
logistic  interests  in  such  areas  as  maintainability, 
supportability ,  reliability,  testability,  human  factors,  spares  & 
repairs  for  a  weapon  system  in  the  same  way  that  a  computer  aided 
design  (CAD)  computer  supports  the  designer  in  the  areas  of 
aerodynamics,  hydrodynamics,  structures,  hydraulics,  electronics, 
mechanical  and  design  engineering.  The  workstation  is  vital 
during  the  design  process  but  it  also  is  essential  in  sustaining 
the  engineering/logistics  activities  throughout  the  total  life 
cycle  of  the  weapon  system.  The  logistics  workstation  1)  has  a 
common  architecture;  2)  is  modular  in  design;  3)  is  configurable 
to  the  various  logistics  functions;  and  4)  is  a  desk-top 
hardware/software  system  that  is  capable  of  manipulating 
textural,  graphical  and  numerical  data.  Such  a  workstation  will 
have  its  own  specialized  logistic  software  which  will,  among 
other  things,  apply  algorithms  for  tradeoff  analyses  and  employ 
complex  logistic  rules  checking  to  ensure  a  supportable  design. 

Basic  Workstation  Characteristics 

o  Hardware-software  upward/downward  compatabi lity 

o  Workstation  interfacing  and  communication 

(Note:  provides  for  flexibility) 

o  Ability  to  exchange  data  among  workstation  vendors 
Assumption:  Application  Programs  exist. 

Workstation  Benefits 

o  Improved  logistic  quality 

o  Improved  logistic  productivity 
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o 


Unification  of  common  logistic  functions 
o  Improved  technical  communication 

o  Cost  saving 

o  Better/quicker  management  decisions 

o  More  efficient  operating/environment 


Current  Logistics  Problems 

o  Lack  of  accessing  data  that  has  been  previously 
created 


o 


o 


Data  information 
to  transfer  data 
Manufacturing  to 


disconnect  (e.g.,  the  inability 
(bases)  from  Design  to 
Spare  Parts  Procurement) 


Inconsistency  of  data 


o  Lack  of  data  transfer  among  developing  areas 
o  Duplication  of  data/multiple  entries  of  same  data 
o  Diverse  implementation  and  development  (e.g., 

cannot  exchange  logistic  models,  and  handle  other 
technological  advances,  etc.) 

o  Lack  of  standard  data  exchange/protocol  (cannot 
transfer  data  from  one  vendor's  hardware 
application  or  software  to  another  vendor's 
hardware  application,  and  software 


B.  RECOMMENDATIONS 

The  CALS  Technical  Issues  Subgroup  recommends  the  following 
steps  in  support  of  a  logistics  workstation  - 

1.  Document  logistics  functional  requirements  including  the 
preparation  of: 

a.  Maintenance  Plans 

b.  Training  manuals 

c.  Technical  Manuals,  total  document  requirements  less 
than  50  pages  of  memory. 
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Document  workstation  configuration  requirements 

a.  Word  Processing 

b.  0-4  megabytes  of  memory 

c.  Graphic  terminals  -  1000  x  1000  resolution 

Survey  industry  systems  and  plans 

a.  Ensure  that  industry  is  tune  with  our  requirements  -Are 
we  under-  or  over-estimating  our  requirements 

Configurations  trade-off  studies  and  characteristics 

analysis 

a.  Narrow  down  our  choices  setting  well  defined  parameters 
in  which  we  are  going  to  operate 

Document  justification  of  workstation  (cost,  R01,  payoff) 

a.  Is  it  a  good  or  bad  idea?  It  is  cost  effective? 

Prepare  Demonstration  Plan 

What  should  be  demonstrated? 

a.  Evaluation  plan/criteria  for  judging  acceptance  of 
demonstration,  e.g.,  response  time,  ease  of  use, 
availability  of  minimum  level  of  software,  expansion 
capability,  etc. 

Workstation  demonstration 


a.  One  or  more  vendors  demonstrating  their  proposed 

workstations  capabilities  (e.g.,  carrying  out  the  Demo 
Plan) 


8.  Analysis  and  evaluation  of  demonstration 

9.  Document  and  publish  demonstration  findings 

Recommendation:  CALS  workstation  specification 
Description,  constraints,... 


226 


REPORT  NO.  22 


DEVELOP  A  KERNEL  LOGISTICS  SYSTEM 

A.  DEFINITION:  Kernel  Logistics  Information  System  is  a 
system  that  allows  computer  automation  to  be  deployed  into  highly 
distributed  data  systems. 

B.  TASKS 

1.  Make  PCASS  (Parts  Control  Automated  Support  System) 
available  to  industry. 

2.  Develop  Federal  Catalog.  Utilize  and  enhance  available 
catalog  to  improve  characterization  of  existing 
inventory  for  preliminary  design  support. 

3.  Develop  digital  description  of  weapon  system  which 
would  provide  digital  equivalent  to  current  or  existing 
engineering/logistic  products. 

4.  Study  logistic  activity  for  developing  the 
documentation  processes: 

develop  data  directory 
augment  field  reporting  system 

5.  Develop  data  bases  which  will  support  preliminary 
design  selection 

develop  logistic  basis  which  will  provide 

intelligence  for  such  design 

emphasize  relational  logistic  functions 

6.  Study  impact  of  data  used  on  DoD  effectiveness 

7.  Study  managerial  aspects  of  non-digital  data  in 
transition  period 

Evaluate  data  protection  technologies 

a.  Severe  environment:  EMP ,  fire  or  crises 

b.  Aging,  archival  preservation 
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c.  Access  control  and  integrity,  reliability 

d.  Redundancy 

9.  Evaluate  data  obsolesence  and  relevancy 
configuration  history 
audit  trails/traceability 

10.  Define  storage  sizing  strategy 

local  high  density  storage,  mass  storage  systems 
access  protocol 

11.  Define  Logistics  Communication  Network 

12.  Perform  Productivity  Study.  Define  potential  impact  on 
existing  logistic  systems. 

13.  Conduct  cost-benefit  analysis.  Define  minimum  funding 
profile . 

14.  Develop  specification  for  a  Kernel  System  on  two 
levels : 

system  level  with  emphasis  on  regulations  and 
acquisition  philosophy 
implementation  level 

distinguish  two  lines:  system  itself  and 
environment  for  the  system 

15.  Study  users'  information  requirements 
-  managerial/hierarchical  approach 
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Action  Items 


1.  Identify  sources  of  data  essential  to  CALS.  (The  fact  is 
that  DoD  does  not  identify  all  its  sources.)  Identify 
requirements  for  generation  of  data  and  needs  for 
maintenance  of  data. 

2.  Develop  a  new  field  reporting  system  that  will  take 
advantage  of  the  new  concepts. 

Demonstration: 

1.  Demonstrate  PCASS  across  DoD  system  functions  in  supporting 
preliminary  design. 

2.  Demonstrate  the  new  field  reporting  system  on  current  weapon 
support  system. 


TIME  SCALE 


SUBJECT 


_  FY _ 

85  86  87  88  89  90  91  92  93  94 


1.  Getting  digital  X  X 
data  into  Govt. 


2.  Funding  X  X 

3.  Studies 

-  to  develop 
logistic  docu¬ 
ment  process  X  X 

-  PCASS,  federal 

catalog  X  X 


4.  Develop  pre¬ 
liminary  specifi¬ 
cation  X  X  X  X  X 


5.  Validation 


X  X  X  X  X 


ASSUMPTIOH:  Each  study  when  started  can  be  completed  within  2 
years  after  authorization. 
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1090  Vermont  Ave,  N.W. 

Washington,  DC  20005 

James  J.  Sikora 

Vice  President,  General  Support 
Test  and  Evaluation 
BDM  Corporation 
1801  Randolph  Road 
Albuquerque,  NM  87106 

Mr.  Richard  Biendenbender 
Evaluation  Research  Corporation 
1755  Jefferson  Davis  Highway,  Suite  800 
Arlington,  V A  22202 


Mr,  E.  B.  Birchfield 
Chief  Program  Engineer, 

Computer  Aided  Design 
McDonnell  Aircraft  Corporation 
P.  O.  Box  516 
St.  Louis,  MO  63166 

David  H.  Wilson 
MIS  IR-15 

Boeing  Aerospace  Company 
P.  O.  Box  3999 
Seattle,  W A  98124 

Mr.  Hal  Resnick 
QUSOFT,  Inc. 

Suite  206 

2755  Hartland  Road 
Falls  Church,  V A  22243 

Mr.  Lee  Rivers 

Hughes  Aircraft 

Building  A-l,  M/S  4C617 

P.  O.  Box  9399 

Long  Beach,  CA  90810-2399 

Mr.  H.  I.  Starr 
TRW  Electronics  and  Defense 
Building  1 19B,  Room  4005 
One  Space  Park 
Redondo  Beach,  CA  90278 

Mr.  Robert  Vermette 
American  Management  Systems 
12th  Floor 

1777  North  Kent  Street 
Arlington,  V A  22209 

Mr.  Michael  Long 
American  Management  Systems 
12th  Floor 

1777  North  Kent  Street 
Arlington,  V A  22209 

Robert  L.  Annett 
Marine  Division  (ML&H) 
Integrated  Logistics  Support 
Westinghouse  Electric  Corporation 
P.  O.  Box  499 
Sunnyvale,  CA  94088 
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Donald  L.  Seidenspinner 
Systems  Engineering,  Integrated 
Logistics  Support 
Grumman  Aerospace  Corporation 
Bethpage,  NY  11714 

Doug  Doerr 

ITT  Aerospace/Optical  Division 

P.  O.  Box  3700 

Ft.  Wayne,  IND  46801 

John  C.  Gebhardt 
Vice  President,  Engineering  and 
Research 

InteiCAD  Corporation 
2525  Riva  Road 
Annapolis,  MD  21401 

Thomas  L.  Nondorf 
Senior  Engineer,  Logistics 
McDonnell  Aircraft  Company 
P.  O.  Box  516 
St.  Louis,  MO  63166 

Richard  Gunkel 
IDA  Consultant 
President,  BITE,  Inc. 

9254  Center  Street 
Manassas,  V A  221 10 

Mary  A.  Klement 

Group  Engineer,  ILS  Engineering 

General  Dynamics 

Convair  Division 

P.  O.  Box  85357 

San  Diego,  CA  92138 

Richard  Alweil 

Director,  Product  Engineering  and  Support 
Hazeltine  Corporation 
Cuba  Hill  Road 
Greenlawn,  NY  11740 

John  Barker 

Director,  Product  Support 
Boeing  Aerospace  Company 
P.  O.  Box  3999,  Mail  Stop  82-09 
Seattle,  WA  98 124-2499 
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Jack  N.  Best 

Corporate  Director,  Productivity 
Programs  and  Plans 
General  Dynamics  Corporation 
Pierre  LaClede  Building 
7733  Forsyth  Street 
St.  Louis,  MO  63105 

Howard  Chambers 

Vice  President,  Logistics 

Rockwell  International 

North  American  Aircraft  Operations 

100  N.  Sepulveda  Boulevard 

Dept.  101-ZT-12 

El  Segundo,  CA  90245 

Harley  Cloud 
Director  of  Technology 
IBM  Federal  System  Division 
6600  Rockledge  Drive 
Bethesda,  MD  20817 

Herman  Correale 

Corporate  Director,  Product  Support 
McDonnell  Aircraft  Company 
Lambert  Field 

Dept.  090,  Building  #1,  Level  3 

P.  O.  Box  516 

St.  Louis,  MO  63166 

Darrell  Cox 

Rockwell  International 

North  American  Aircraft  Operations 

201  North  Douglas  Street 

Dept.  1 18,01 1-GC02 

El  Segundo,  California  90245 

W.  R.  Phillips 

Vice  President,  Enginering 

Newport  News  Shipbulding  and  Dry  Dock 

4101  Washington  Avenue 

Newport  News,  VA  23607 

Mike  Deeter 

Manager,  Advanced  Logistics 
North  American  Aircraft  Operations 
Rockwell  International 
100  N.  Sepulveda  Boulevard 
El  Segundo,  CA  90245 


John  Dutton 
Director,  McAir  IRM 
McDonnell  Aircraft  Company 
Dept.  52,  Level  1,  Room  380 
6951  N.  Hanley 
Hazelwood,  MO  63042 

George  Fredericks 

Manager,  Logistics  R&D  Engineering 
IBM  Federal  Systems  Division 
Mail  Stop  864/5 A58 
1 100  Frederick  Pike 
Gaithersburg,  MD  20879 

James  A.  Palmer 

Director,  Engineering  Administration 
Newport  News  Shipbuilding  and  Dry  Dock 
4101  Washington  Avenue 
Newport  News,  VA  23607 

Mark  P.  Pittenger 
Boeing  Aerospace  Company 
20403  68th  Avenue,  South 
Kent,  WA  98032 

John  Tierney 

Director,  Logistics  Requirements 
General  Dynamics  Corporation 
Fort  Worth  Division 
P.  O.  Box  748,  Mail  Zone  1835 
Fort  Worth,  TX  76101 

John  Willis 
Rockwell  International 
100  N.  Sepulveda  Boulevard 
Dept.  115-GD-10 
El  Segundo,  CA  90245 

John  Anderson 
Boeing  Aerospace 
P.  O.  Box  3707,  Mail  Stop  03-80 
Seattle,  WA  98124 

George  Beiser 
3001  N.  Florida  Street 
Arlington,  VA  22207 

Ray  Bourn 

IBM  Federal  Systems  Division 
Mail  Stop  102-072 
9500  Godwin  Drive 
Manassas,  V  A  22100 
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Robert  R.  Brown 
Hughes  Aircraft  Co. 

Bldg.  E-l,  Mail  Stop  A1 16 
P.  O.  Box  902 

2000  E.  El  Segundo  Boulevard 
El  Segundo,  CA  90245 

William  E.  Florance 
Eastman  Kodak  Company 
Advanced  Systems  Division 
Bldg.  601,  Kodak  Park 
Rochester,  NY  14650 

Gary  L.  Foreman 

Senior  Scientist,  Advanced  Program 
Support  Lab 
Hughes  Aircraft  Co. 

Bldg.  276/Mail  StopT42 
Canoga  Park,  CA  91304 

Judson  French,  Jr. 

Program  Manager,  Advanced  Development 
Support  Systems 
Westinghouse  Electric  Corp. 

Mail  Stop  7034 
1 1 1 1  Schilling  Road 
Hunt  Valley,  MD  2 1031 

Siegfried  Goldstein 
Siegfried  Enterprises 
7  Dulittle  Street 
North  Babylon,  NY  11703 

Erich  Hausner 
Lockheed  California  Co. 

Dept.  72-78  90-3  A-l 
Burbank,  CA  91520-7278 

Fred  Hirt 
Litton/Mellonics 
Suite  8206 

490  L’Enfant  Plaza  East,  SW 
Washington,  DC  20024 

Frank  M.  Krantz 
Westinghouse  Electric  Corp. 

P.  O.  Box  1693,  Mail  Stop  4410 
Baltimore,  MD  21203 

W.  D.  Lewis 

General  Dynamics  Corporation 
DSD  Headquarters 
12101  Woodcrest  Executive  Drive 
St.  Louis,  MO  63141 
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Fred  Macey 

Dept.  63-11,  Zone  333 

Lockheed  Georgia  Co. 

Marietta,  GA  30063 

Mark  Palatchi 
Dept.  63-11,  Zone  333 
Lockheed  Georgia  Co. 

Marietta,  GA  30063 

William  W.  Tunnicliffe 
Graphics  Communications  Association 
1730  N.  Lynn  Street,  Suite  604 
Arlington,  VA  22209 

Warren  Mathews 

Corporate  Vice  President  for  Product 
Effectiveness 
Hughes  Aircraft  Co. 

Bldg.  C-A,  Mail  Stop  B195 
200  N.  Sepulveda  Boulevard 
El  Segundo,  CA  90245 

Bob  Gulcher 

Vice  President,  Research  and  Development 

Rockwell  International 

Dept.  101-GB-08 

P.  O.  Box  92098 

Los  Angeles,  CA  90009 

Jack  Osborn 

Structural  Dynamics  Research  Corporation 
2000  Eastman  Drive 
Milford,  OH  45150 

Patrick  M.  Dallosta 

Logistics  Engineering  Associates,  Inc. 

P.  O.  Box  3357 
Annapolis,  MD  21403 

R.  Thomas  Moore,  Jr.,  CPL 

Vice  President,  Operations 

Logistics  Management  Engineering,  Inc. 

P.  O.  Box  3318 
Annapolis,  MD  21403 

SYSCON  Corporation 

1000  Thomas  Jefferson  St.,  N.W. 

Washington,  DC  20007 

ATTN:  Pat  Moore 

Georgetown  Division 
4th  Floor 
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Jim  Stemple 
EDS 

Crystal  Square  2 
Suite  912 

1725  Jefferson  Davis  Highway 
Arlington,  VA  22202 

James  D.  Moroney 
Midwest  Manuals,  Inc. 

1  West  Interstate  Street 
Bedford,  OH  44146 

J.  William  T.  Smith 
Systems  Management 
Engineering  Corporation 
1054  Cedar  Ridge  Court 
Annapolis,  MD  21403 

Dick  Fleeson 

Consultants  and  Designers 
1725  Jefferson  Davis  Highway 
-  Plaza  Level 
Arlington,  VA  22202 

Floyd  Hutzenbiler 
BDM  Corporation 
10260  Old  Columbia  Road 
Columbia,  MD  21046 

Mr.  Robert  Nemmers 
General  Electric  Company 
12030  Sunset  Hills  Road 
Reston,  VA  22090 

Donald  G.  Buxton 
Assistant  Program  Manager  for 
Integrated  Logistics  Support 
TRW,  Inc. 

7600  Colshire  Drive 
McLean,  VA  22102 
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